Change:
protocol stack(s).  They are collected into a TransportProperties object to be passed into a Preconnection object: <del> Individual properties are then added to the TransportProperties Object: </del> <ins> Individual properties are then set on the TransportProperties Object. Setting a Transport Property to a value overrides the previous value of this Transport Property. </ins> Selection Properties of type "Preference" can be frequently used. Implementations MAY therefore provide additional convenience

Discussion:
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.
NAME - I agree with the response by NAME in , which concludes: "If I misunderstood, I think the best approach is to indeed allow specifying multiple (Preference, Enumeration) in a single Set() call." KISS, I say :)
If calling Set() 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 don'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 Interface 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 Set() 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 NAME 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 Interface and PvD.