Draft: draft-ietf-taps-interface

Commentary: If I understand correctly , we 're staying with the current master . Therefore , here 's my PR to - I think we always want to override , and if we override , calling it Set ( ) makes this clearer than Add ( ) . For Security Parameters , perhaps it should be possible to add multiple identities , ciphersuites , etc . But that 's out of scope for this PR . 
 - I agree with the response by in , which concludes : " If I misunderstood , I think the best approach is to indeed allow specifying multiple ( Preference , Enumeration ) in a single  ( ) call . " KISS , I say :) 
 If calling  ( ) for Security Parameters overrides ( ) , then the API should allow setting a Security Parameter to multiple values , e.g. , using a list . This would be needed , e.g. , to set multiple cipher suites . I do n't think we need to make this overly formal . Adding one sentence to the Security Parameters section should be enough . Right ? 
 We should also consider whether setting multiple values is not only needed for Security Properties , but also for Transport Properties like  and PvD. This one is more complex , as it comes with a tuple . Not sure whether just adding a sentence and making accept a list auf values is the right approach or if we should have an call for that – The former is nicer in the API document , the latter seems more appropriate when thinking about how one would use the API 
 Agree that we want to enable setting multiple values for Interface and PvD , but I thought that 's why their Type is " Set ( Preference , Enumeration ) " - I took this to mean that it 's multiple Interfaces , each with a Preference . But reading the text again , maybe I misunderstood . If I misunderstood , I think the best approach is to indeed allow specifying multiple ( Preference , Enumeration ) in a single  ( ) call . 
 Reopening this because I still think we should add a sentence to Section 5.3.1 of the API draft , perhaps simply saying that the implementation should support setting multiple values for a single Security Parameter . Still not sure about the Interface and PvD properties - I think that making set accept a list auf values , as suggested by is the right approach , but perhaps it 's worth adding a sentence to explain this to their sections as well . 
 Interface and PvD are already " sets of tuples " . We could have a sentence to clarify that this is a " collection " , or maybe just call it " collection " . Maybe also add a sentence to the data types section to indicate that they can have collections . Mention in text that security parameters can take collections . 
 We should rename these if they are really setting and not adding . 
 The original idea to call it was to emphasise that we add these properties to the set the system needs to consider . As we removed all Intents and decided to be much more conservative here , I agree is the better choice for the current API 
 Regarding continuing with the current master : yes , correct . About this PR : looks fine to me ! Thanks a lot for doing thisThank you for changing this – makes sense given that we removed the Intents . After applying this PR , we should consider whether setting multiple values is not only needed for Security Properties ( as stated in ) , but also for Transport Properties like  and PvD.
Paragraph (version B):
Individual properties are then set on the TransportProperties Object.
Setting a Transport Property to a value overrides the previous value
of this Transport Property.