Draft: draft-ietf-taps-arch

Commentary: Changed example of a Specialized Feature ( non - minset ) from " encryption " to " automatic handover or failover " , as suggested by  in . If anyone has an alternative suggestion how to word this , I 'm open . Ideas for alternative solutions include : Go back to the " encryption " example , but do not make " encryption " sound like a generic feature but rather talk about specific security protocols , e.g. : " For example , if an application requires encryption of its transport data , it could select a specific security protocol . In this case , only protocol stacks that include this security protocol are eligible to be used . " Find a different example Give up and throw out the example entirely , maybe even changing what a " specialized feature " is Looking for guidance from the authors here :) 
 The architecture draft has a few parts where it needs to be aligned with how we handle security protocols now . One such part is Section 3.2 , " Access to Specialized Features " . Right now it says : " Other specialized features , however , could be strictly required by an application and thus constrain the set of protocols that can be used . For example , if an application requires encryption of its transport data , only protocol stacks that include a transport security function are eligible to be used . " To me , this sounds like an application could just request " Encryption : Require " and then any security protocol that provides this function could be used . That 's not how we think about security protocols anymore . So we need to change that example . I have n't really found another example for a " specialized feature " that might be required - " specialized feature " apparently means " feature not in minset " - so I suggest we stick with the security example , but change the wording . For example , we could just say , " For example , if an application requires encryption of its transport data , it could select a specific security protocol . In this case , only protocol stacks that include this security protocol are eligible to be used . " However , then it 's not strictly a feature anymore ... right ? What do the authors think ? 
 It sounds like a new example , unrelated to security , should be chosen for the text . 
 Yes , I think we need a new example . Could a multuipath example do , requiring handover / failover support ( or some suitable option available after resolving that issue ) . 
 I fear changing the example will not solve the overall problem . We really need to make a decision how we go ahead with the non - goal statement from the security draft . Ways forward : Automagic security is a non - goal for the security draft , but goal for the triplet ( no text changes , but will hunt us on the next review ) Work around this limitation by adding profiles for tls / quic - v1 equivalent transports ( must be profiles , as we decided explicit protocol selection is not part of the portable API ) Get rid of examples from the main text at all and move them to the  as we can not provide relevant examples without using non - portable APIs
Paragraph (version A):
Other specialized features, however, could be strictly required by an
application and thus constrain the set of protocols that can be used.
For example, if an application requires encryption of its transport
data, only protocol stacks that include a transport security function
are eligible to be used.  A Transport Services API MUST allow
applications to define such requirements and constrain the system's
options.  Since such options are not part of the core/common
features, it will generally be simple for an application to modify
its set of constraints and change the set of allowable protocol
features without changing the core implementation.
Paragraph (version B):
Other specialized features, however, could be strictly required by an
application and thus constrain the set of protocols that can be used.
For example, if an application requires support for automatic
handover or failover for a Connection, only protocol stacks that
provide this feature are eligible to be used, e.g., protocol stacks
that include a multipath protocol or a protocol that supports
connection migration.  A Transport Services API MUST allow
applications to define such requirements and constrain the system's
options.  Since such options are not part of the core/common
features, it will generally be simple for an application to modify
its set of constraints and change the set of allowable protocol
features without changing the core implementation.