Change:
This addresses two issues related to protocol stack equivalence: TCP and UDP can now be equivalent if the application does not care about message boundaries (see mailing list discussion in July 2019) Security protocol and parameters need to be equivalent, not "features" which implied abstract security features. Basically, equivalent stacks are all stacks that satisfy whatever the application requested. If you want to race different security protocols (like TLS 1.2 and 1.3), your application has to specify that it considers these protocol equivalent. Question to authors: Should the SHOULD in 3. become a MUST?
Regarding the SHOULD, I'd rather leave it as a SHOULD for now, to give some wiggle room to implementations.
Under "Protocol Stack Equivalence", for example, text like needs to change to conform to the rework of the security document. This is related to .
Yes, I think this is part of the "protocol stack equivalence" issue . As is assigned to me, I'll just self-assign this one and close both once this is done.
Fixed by
Per the architecture draft, only protocol stacks that are equivalent can be safely raced. What is the expected behavior if selection properties are set in such a way that the resulting candidate set includes protocol stacks that are not equivalent? Would the selection properties simply be treated as invalid?
To me "equivalent" relates to either candidate would provide the set of functions needed. At the risk I don't answer your question: My take is that one can always define policy and API properties that produce a useless outcome. It's not the job of a TAPS system to validate these (although someone may like to try that as a separate sanity checking tool); in just the same way that someone can write code that doesn't implement an algorithm. The goal is rather that if this specifies "sensible" properties and policy you get the required outcome. You may get no connection or something unexpected if the request is not well-founded.
Right, so if an application chooses to provide properties that allow both TCP and UDP the implementation would race those two which would result in a default win for UDP, is that correct?
I agree, and I'd say the answer to your question is yes. Of course, later you may find that UDP doesn't really work on the path for the given port, and then it would be great to have an open TCP connection available to fall back to.
I guess we should define "equivalent protocol stacks" a little less rigorous in the architecture document. For an application that does not care about message boundaries, and reliable transport and has its own congestion control, protocol stacks with TCP and UDP may indeed be equivalent with respect to the application's requirements. This would require to rewrite 1. of the enumeration in Section 4.2.3 which could use a second look anyway, because it mixes up application requirements in sense of interface behaviour and application protocols that directly depend on specific transport protocols beneath, which is what PR is all about.
See also mailing list discussion in July 2019.
We also need to say here what "equivalence" means for security. Right now, Security Considerations says "As described above in Section 4.2.3, if a Transport Services system races between two different Protocol Stacks, both MUST use the same security protocols and options." I think if we consider equivalence as "you can use whatever stack that satisfies the things that the application requested", this should also apply to security. Now that the application has to explicitly select a security protocol, I think it should also be allowed for the application to say that multiple security protocols are fine. Like, allow applications to say "Use TLS 1.3 if available, but if not, TLS 1.2 is also fine" (instead of failing).
Fixed by
Nice!

Discussion:
parallel (see racing), then they are considered to be "equivalent". Equivalent Protocol Stacks need to meet the following criteria: <del> Both stacks MUST offer the same interface to the application for connection establishment and data transmission.  For example, if one Protocol Stack has UDP as the top-level interface to the application, then it is not equivalent to a Protocol Stack that runs TCP as the top-level interface.  Among other differences, the UDP stack would allow an application to read out message boundaries based on datagrams sent from the remote system, whereas TCP does not preserve message boundaries on its own. </del> <ins> Both stacks MUST offer the interface requested by the application for connection establishment and data transmission.  For example, if an application requires preservation of message boundaries, a Protocol Stack that runs UDP as the top-level interface to the application is not equivalent to a Protocol Stack that runs TCP as the top-level interface.  A UDP stack would allow an application to read out message boundaries based on datagrams sent from the remote system, whereas TCP does not preserve message boundaries on its own, but needs a framing protocol on top to determine message boundaries. </ins> Both stacks MUST offer the transport services that are required by the application.  For example, if an application specifies that it

Stack as long as providing this would not conflict with any other application-requested properties. <del> Both stacks MUST offer the same security properties.  The inclusion of transport security protocols I-D.ietf-taps-transport- security in a Protocol Stack adds additional restrictions to Protocol Stack equivalence.  Security features and properties, such as cryptographic algorithms, peer authentication, and identity privacy vary across security protocols, and across versions of security protocols.  Protocol equivalence ought not to be assumed for different protocols or protocol versions, even if they offer similar application configuration options.  To ensure that security protocols are not incorrectly swapped, Transport Services systems SHOULD only automatically generate equivalent Protocol Stacks when the transport security protocols within the stacks are identical.  Specifically, a transport system would consider protocols identical only if they are of the same type and version.  For example, the same version of TLS running over two different transport protocol stacks are considered equivalent, whereas TLS 1.2 and TLS 1.3 RFC8446 are not considered equivalent. </del> <ins> Both stacks MUST offer security protocols and parameters as requested by the application I-D.ietf-taps-transport-security. Security features and properties, such as cryptographic algorithms, peer authentication, and identity privacy vary across security protocols, and across versions of security protocols. Protocol equivalence ought not to be assumed for different protocols or protocol versions, even if they offer similar application configuration options.  To ensure that security protocols are not incorrectly swapped, Transport Services systems SHOULD only automatically generate equivalent Protocol Stacks when the transport security protocols within the stacks are identical. Specifically, a transport system would consider protocols identical only if they are of the same type and version.  For example, the same version of TLS running over two different transport protocol stacks are considered equivalent, whereas TLS 1.2 and TLS 1.3 RFC8446 are not considered equivalent.  However, Transport Services systems MAY allow applications to indicate that they consider two different transport protocols equivalent, e.g., to allow fallback to TLS 1.2 if TLS 1.3 is not available. </ins> 4.2.4.