If all of the leaf nodes fail to connect during racing, i.e. none of the configurations that satisfy all requirements given in the Transport Properties actually work over the available paths, then the <del> transport system should report an InitiateError to the application. An InitiateError event should also be generated in case the transport system finds no usable candidates to race. </del>  4.5. Data Unit: Byte-stream <del> the Transport Services API mappings for MPTCP are identical to TCP. </del>  MPTCP adds support for multipath properties, such as "multipath" and "multipathPolicy". UDP Connections can only generate errors on initiation due to port conflicts on the local system. <del> Once in use, UDP throws "soft errors" (ERROR.UDP(-Lite)) upon receiving ICMP notifications indicating failures in the network. Additional information can also be provided when this is available to the system (e.g.  ICMP error code and quoted packet header). </del>  LISTEN.UDP.  Calling "Listen" for UDP binds a local port and prepares it to receive inbound UDP datagrams from peers. the local port reservation. Calling "Abort" on a UDP Connection (ABORT.UDP(-Lite)) is <del> identical to calling "Close". </del>  Calling "CloseGroup" on a UDP Connection (ABORT.UDP(-Lite)) is identical to calling "Close" on this Connection and on all Endpoint must be configured with a group IP address and a port. Calling "Initiate" on a UDP Multicast Receive Connection causes an <del> immediate InitiateError.  This is an unsupported operation. </del>  Calling "InitiateWithSend" on a UDP Multicast Receive Connection <del> causes an immediate InitiateError.  This is an unsupported </del>  operation. A UDP Multicast Receive Connection is ready once the system has received traffic for the appropriate group and port. <del> UDP Multicast Receive Connections generate an InitiateError indicating that joining a multicast group failed if Initiate is </del>  called.  LISTEN.UDP.  Calling "Listen" for UDP Multicast Receive binds a local port, prepares it to receive inbound UDP datagrams from peers, and issues a multicast host join.  If a Remote Endpoint stream id assignment procedure described above.  If there are not enough streams available, ADD_STREAM.SCTP must be called. <del> When this value is changed, or a Message with Message Property "msgPriority" is sent, and there are multiple Connection objects assigned to the same SCTP association, CONFIGURE_STREAM_SCHEDULER.SCTP is called to adjust the priorities of streams in the SCTP association. </del> SEND.SCTP.  Message Properties such as "msgLifetime" and "msgOrdered" map to parameters of this primitive. AbortGroup: Calling "AbortGroup" calls ABORT.SCTP, immediately closing all Connections in the SCTP association.  11. RFC-EDITOR: Please remove this section before publication.

This PR covers steps 1 and 2 in . When aligning the error events for UDP multicast I also noticed that the text for UDP was not correct as soft errors do not generate ConnectionError events so also attempted to fix this.
NAME what's the reason for having Abort cause an error, rather than just moving to closed?
NAME This comes from the API draft, which says:
Great, thank you!

If all of the leaf nodes fail to connect during racing, i.e. none of the configurations that satisfy all requirements given in the Transport Properties actually work over the available paths, then the  <ins> transport system should report an EstablishmentError to the application.  An EstablishmentError event should also be generated in case the transport system finds no usable candidates to race. </ins> 4.5. Data Unit: Byte-stream  <ins> The Transport Services API mappings for MPTCP are identical to TCP. </ins> MPTCP adds support for multipath properties, such as "multipath" and "multipathPolicy". UDP Connections can only generate errors on initiation due to port conflicts on the local system.  <ins> UDP Connections can only generate connection errors in response to "Abort" calls.  (Once in use, UDP Connections can also generate "SoftError" Events (ERROR.UDP(-Lite)) upon receiving ICMP notifications indicating failures in the network.) </ins> LISTEN.UDP.  Calling "Listen" for UDP binds a local port and prepares it to receive inbound UDP datagrams from peers. the local port reservation. Calling "Abort" on a UDP Connection (ABORT.UDP(-Lite)) is  <ins> identical to calling "Close", except that the Connection will send a ConnectionError Event rather than a Closed Event. </ins> Calling "CloseGroup" on a UDP Connection (ABORT.UDP(-Lite)) is identical to calling "Close" on this Connection and on all Endpoint must be configured with a group IP address and a port. Calling "Initiate" on a UDP Multicast Receive Connection causes an  <ins> immediate EstablishmentError.  This is an unsupported operation. </ins> Calling "InitiateWithSend" on a UDP Multicast Receive Connection  <ins> causes an immediate EstablishmentError.  This is an unsupported </ins> operation. A UDP Multicast Receive Connection is ready once the system has received traffic for the appropriate group and port.  <ins> UDP Multicast Receive Connections generate an EstablishmentError indicating that joining a multicast group failed if "Initiate" is </ins> called. <ins> The only ConnectionError generated by a UDP Multicast Receive Connection is in response to an "Abort" call. </ins> LISTEN.UDP.  Calling "Listen" for UDP Multicast Receive binds a local port, prepares it to receive inbound UDP datagrams from peers, and issues a multicast host join.  If a Remote Endpoint stream id assignment procedure described above.  If there are not enough streams available, ADD_STREAM.SCTP must be called.  SEND.SCTP.  Message Properties such as "msgLifetime" and "msgOrdered" map to parameters of this primitive. AbortGroup: Calling "AbortGroup" calls ABORT.SCTP, immediately closing all Connections in the SCTP association. <ins> In addition to the API mappings described above, when there are multiple Connection objects assigned to the same SCTP association, SCTP can support Connection properties such as "connPriority"and "connScheduler" where CONFIGURE_STREAM_SCHEDULER.SCTP can be called to adjust the priorities of streams in the SCTP association. </ins> 11. RFC-EDITOR: Please remove this section before publication.


Numeric (non-negative) or "Disabled" <del> Implementation-defined </del>  A Transport Services API can request a protocol that supports sending keep alive packets keep-alive.  If this property is Numeric, it

URL we have two types... but the default is Implementation-defined. Implementation-defined type is never defined or described. This needs to be fixed.

Numeric (non-negative) or "Disabled"  <ins> "Disabled" </ins> A Transport Services API can request a protocol that supports sending keep alive packets keep-alive.  If this property is Numeric, it


Note that configuring Connection Properties and Message Properties on Preconnections is preferred over setting them later.  Early specification of Connection Properties allows their use as additional <del> input to the selection process.  Protocol Specific Properties, which </del>  enable configuration of specialized features of a specific protocol, see Section 3.2 of I-D.ietf-taps-arch, are not used as an input to the selection process, but only support configuration if the properties, i.e., for properties that are not specific to a protocol and are defined in an RFC. <del> Protocol Specific Properties MUST use the protocol acronym as the Namespace, e.g., "tcp" for TCP specific Transport Properties.  For IETF protocols, property names under these namespaces SHOULD be defined in an RFC. </del>  Vendor or implementation specific properties MUST use a string identifying the vendor or implementation as the Namespace.  Namespaces for each of the keywords provided in the IANA protocol numbers registry (see https://www.iana.org/assignments/protocol- <del> numbers/protocol-numbers.xhtml) are reserved for Protocol Specific </del>  Properties and MUST NOT be used for vendor or implementation-specific properties.  Avoid using any of the terms listed as keywords in the protocol numbers registry as any part of a vendor- or implementation- transport protocol stack.  Generic Connection Properties are defined in connection-props below. <del> Protocol Specific Properties are defined in a transport- and </del>  implementation-specific way to permit more specialized protocol <del> features to be used.  Too much reliance by an application on Protocol Specific Properties can significantly reduce the flexibility of a transport services implementation to make appropriate selection and configuration choices.  Therefore, it is RECOMMENDED that Protocol Properties are used for properties common across different protocols and that Protocol Specific Properties are only used where specific protocols or properties are necessary. </del>  The application can set and query Connection Properties on a per- Connection basis.  Connection Properties that are not read-only can Message Properties can be set and queried using the Message Context: <del> These Message Properties may be generic properties or Protocol Specific Properties. </del>  For MessageContexts returned by send Events (see send-events) and receive Events (see receive-events), the application can query

This implements the change I suggested in , and it also replaces "Protocol Specific Properties" with "protocol-specific Properties".
The example could be even more useful perhaps: /Protocol-specific Properties MUST use the protocol acronym as the Namespace (e.g., a connection could support a TCP-specific Transport Property, such as {{tcp-uto}}, in a protocol-specific parameter called ./
Done, in line with your suggestion. The wording is slightly different for several reasons: really using would be confusing because that particular property doesn't exist (there are, if you will, sub-properties). The {{tcp-uto}} reference expands as "Section ...", so using "such as" doesn't work; it's not a "protocol-specific parameter" but a "protocol-specific property". Oh and the connection is a Connection :-)
Specific suggestion you could start from: "For IETF protocols, the name of a Protocol-specific Property SHOULD be specified in a IETF document published in the RFC Series."
P.S. I would also be happy to continue with another recommendation, for additional transport properties that was proposed which says something like add it to the RFC.
URL are all the current protocols defined their Namespace in the respective RFCs? can we put a example reference? can we be more detailed on "SHOULD be defined in an RFC" actually mean?
My understanding is that this is meant as guidance for implementations, and for future RFCs to be written. If I write a TAPS system and provide a property that exists in QUIC only (and cannot reasonably be mapped to other protocols), then I should call it "quic.propertyname" - much like the TCP-specific properties in section 8.2. Similarly, future RFCs should define such namespaces if they offer properties that are protocol-specific. It seems that this second sentence poses quite a burden on the IETF in general, and may not be realistic - will people follow this? Suggested solution: remove the second sentence, and add a reference to section 8.2 to the first sentence to show an example.
I'm not sure removing the sentence is the right thing to do. To me this is like the rules to add to a registry, and we should simply describe what they ought to do: what I thought was intended was that the IETF ought to publish the binding in a RFC that defines the thing with a property, or (if necessary) a separate RFC.
It sounded like a too broad demand to make - e.g., RFC 9000 should then have such stuff in it. What if we would phrase this more like, e.g.: "Future RFCs that extend Transport Service systems SHOULD define property names under these namespaces."
I don’t read the problem the same here… your text suggests a property name needs to be in the spec itself - which might be good — but is more than my proposal that said the property name for transport systems SHOULD be defined in the RFC series. Although we might decide to say both. The potential problem as a WG Chair here is that there is no mechanism to remind or check that this is done. To me, it seems like if we had a registry, then we would have an IETF process to encourage ID authors to do the things in 4.1 and 4.2 of interface.
Ok, the phrase "SHOULD be in the RFC series" makes this leave the domain of my IETF knowledge - are we talking about an IANA registry here? Can we use a capital SHOULD as a request to IANA? Or what other form would that take? What would it mean to make such a SHOULD request to the IETF ("RFC series") as a whole? Suggestion: I update my PR to not remove the sentence, merge the PR without closing this issue, and you propose text?

Note that configuring Connection Properties and Message Properties on Preconnections is preferred over setting them later.  Early specification of Connection Properties allows their use as additional  <ins> input to the selection process.  Protocol-specific Properties, which </ins> enable configuration of specialized features of a specific protocol, see Section 3.2 of I-D.ietf-taps-arch, are not used as an input to the selection process, but only support configuration if the properties, i.e., for properties that are not specific to a protocol and are defined in an RFC.  <ins> Protocol-specific Properties MUST use the protocol acronym as the Namespace (e.g., a "tcp" Connection could support a TCP-specific Transport Property, such as the user timeout value, in a protocol- specific property called "tcp.userTimeoutValue" (see tcp-uto). </ins> Vendor or implementation specific properties MUST use a string identifying the vendor or implementation as the Namespace. <ins> For IETF protocols, the name of a Protocol-specific Property SHOULD be specified in an IETF document published in the RFC Series. </ins> Namespaces for each of the keywords provided in the IANA protocol numbers registry (see https://www.iana.org/assignments/protocol-  <ins> numbers/protocol-numbers.xhtml) are reserved for protocol-specific </ins> Properties and MUST NOT be used for vendor or implementation-specific properties.  Avoid using any of the terms listed as keywords in the protocol numbers registry as any part of a vendor- or implementation- transport protocol stack.  Generic Connection Properties are defined in connection-props below.  <ins> Protocol-specific Properties are defined in a transport- and </ins> implementation-specific way to permit more specialized protocol  <ins> features to be used.  Too much reliance by an application on protocol-specific Properties can significantly reduce the flexibility of a transport services implementation to make appropriate selection and configuration choices.  Therefore, it is RECOMMENDED that Protocol Properties are used for properties common across different protocols and that Protocol-specific Properties are only used where specific protocols or properties are necessary. </ins> The application can set and query Connection Properties on a per- Connection basis.  Connection Properties that are not read-only can Message Properties can be set and queried using the Message Context:  <ins> These Message Properties may be generic properties or protocol- specific Properties. </ins> For MessageContexts returned by send Events (see send-events) and receive Events (see receive-events), the application can query


to the application.  The application is responsible for handling any corruption within the non-protected part of the message RFC8085.  A special value of 0 means that a received packet may also have a zero <del> checksum field. </del>  8.1.2. sent by the application and the tradeoffs the application is prepared to make in path and protocol selection to receive that desired treatment.  When the capacity profile is set to a value other than <del> Default, z Transport Services system SHOULD select paths and </del>  configure protocols to optimize the tradeoff between delay, delay variation, and efficient use of the available capacity based on the capacity profile specified.  How this is realized is implementation- infinite <del> The Lifetime specifies how long a particular Message can wait to be sent to the Remote Endpoint before it is irrelevant and no longer needs to be (re-)transmitted.  This is a hint to the Transport Services implementation - it is not guaranteed that a Message will not be sent when its Lifetime has expired. </del>  Setting a Message's Lifetime to infinite indicates that the application does not wish to apply a time constraint on the

This is my attempt to address items 2, 3 and 4. My suggestion is not to do anything about item 1 (referencing -arch), because we already do this so often and IMO it won't improve the document to add yet another reference. See also the discussion in .
These are some minor comments (mostly editorial) /nits, that would be best to address before going for IETF Last call but can be taken care during or after the IETF LC. Section 3 should reference architecture document. We are using concepts and definitions from the architecture document and lets be specific about it. Of we can mention this in the terminology section. Section 8.1.1: the description of Full Coverage is given in section 9.1.3.6. Either forward ref that section where it is explained or move the text in section 8.1.1. Section 8.1.6 : says - >When the capacity profile is set to a value other than Default, z Transport Services system SHOULD select paths and configure protocols to optimize the tradeoff between delay, delay variation, and efficient use of the available capacity based on the capacity profile specified. here "z" ?? Section 9.1.3.1 : says - >The Lifetime specifies how long a particular Message can wait to be sent to the Remote Endpoint before it is irrelevant and no longer needs to be (re-)transmitted. can we describe whether this wait till the Message is sent out of the TAPS system or will the wire (which might include other processing delay by the system)?
Regarding the first item: I think this is overkill. Section 1 begins with: "This document specifies an abstract application programming interface (API) that specifies the interface component of the high-level Transport Services architecture defined in [I-D.ietf-taps-arch]." Section 2 begins with "The design of the API specified in this document is based on a set of principles, themselves an elaboration on the architectural design principles defined in [I-D.ietf-taps-arch]. " - adding something like this to section 3 or section 1.1 too is not making anything clearer, IMO.
The problem I see is that in section 3 we are describing the Connection and Preconnection again. Note that I am using the word "describing" as those are already defined and described in the Arch doc we just need to ref them or say see there in the Interface doc. I would like to avoid the situation that readers are confused and any future update to the Interface doc is problematic to decide which definition/description to preserve. I think just adding a sentence in the terminology section saying things are defined in Arch document make sense. But hej, this is a minor comment so...

to the application.  The application is responsible for handling any corruption within the non-protected part of the message RFC8085.  A special value of 0 means that a received packet may also have a zero  <ins> checksum field, and the enumerated value "Full Coverage" means that the entire Message needs to be protected by a checksum. </ins> 8.1.2. sent by the application and the tradeoffs the application is prepared to make in path and protocol selection to receive that desired treatment.  When the capacity profile is set to a value other than  <ins> Default, the Transport Services system SHOULD select paths and </ins> configure protocols to optimize the tradeoff between delay, delay variation, and efficient use of the available capacity based on the capacity profile specified.  How this is realized is implementation- infinite  <ins> The Lifetime specifies how long a particular Message can wait in the Transport Services system before it is sent to the Remote Endpoint. After this time, it is irrelevant and no longer needs to be (re-)transmitted.  This is a hint to the Transport Services implementation - it is not guaranteed that a Message will not be sent when its Lifetime has expired. </ins> Setting a Message's Lifetime to infinite indicates that the application does not wish to apply a time constraint on the


process of identifying options for connecting, such as resolution of the Remote Endpoint, occurs in response to the Initiate call. <del> Listen: Enables a listener to accept incoming Connections.  The </del>  Listener will then create Connection objects as incoming connections are accepted (events).  Listeners by default register with multiple paths, protocols, and Local Endpoints, unless

URL The use of Cap 'C' in the first sentence for connection is confusing. The Connection object is created after the incoming connections are accepted. The Cap C makes it assume that it not that case and create an expectation that the remote is also a TAPS implementation.

process of identifying options for connecting, such as resolution of the Remote Endpoint, occurs in response to the Initiate call.  <ins> Listen: Enables a listener to accept incoming connections.  The </ins> Listener will then create Connection objects as incoming connections are accepted (events).  Listeners by default register with multiple paths, protocols, and Local Endpoints, unless


set of allowable protocol features without changing the core implementation.  3.3. A Transport Services implementation can select Protocol Stacks based

URL If an application wishes to use a special feature then if might need to adjust itself if that special feature is not applicable to the Connection Object it gets/ gets created for. Should there be no requirement(at least recommendation) on getting this information back? The application can ask a specialized feature in a way that it gets what it wants or the communication MUST fail. In such case the should be a requirement on the application to be specific about it or?
The API solves this in two ways: We have a preference-type that allows the application to explicitly state that it requires/prefers/does-not-care/wants-to-avoid/prohibits each feature. After the establishment, the application can query each feature and gets a boolean back whether it is present or not. Should we add this as a forward reference here or at least hint at the solution?
Hint at the solution sounds like a very good approach to me.

set of allowable protocol features without changing the core implementation. <ins> To control these specialized features, the application can declare its preference - whether the presence of a specific feature is prohibited, should be avoided, can be ignored, is preferred, or is required in the Pre-Establishment phase.  An implementation of a Transport Services API would honor this preference and allow the application to query the availability of each specialized feature after a successful establishment. </ins> 3.3. A Transport Services implementation can select Protocol Stacks based


3.3. <del> A Transport Services implementation can select Protocol Stacks based on the Selection and Connection Properties communicated by the application, along with any security parameters.  If two different Protocol Stacks can be safely swapped, or raced in parallel (see racing), then they are considered to be "equivalent".  Equivalent Protocol Stacks are defined as stacks that can provide the same Transport Properties and interface expectations as requested by the application. </del>  The following two examples show non-equivalent Protocol Stacks:

URL Here it seems we are defining "equivalent" twice. I would rather write - >Equivalent Protocol Stacks are defined as stacks that can provide the same Transport Properties and interface expectations as requested by the application. and the equivalent stacks can be swapped or raced. Also in the example - it is not clear that swapping and racing in important, however, application provided properties are. Apart from this I also think the title and content is mismatching. I found the last paragraph talking about swapping and racing focusing on security. Here we are imposing requirements on swapping and racing. These are very important for the security consideration and to me should get its own title and section separated from selection of equivalence.
LGTM!Looks good

3.3.  <ins> A Transport Services implementation can attempt and select between multiple Protocol Stacks based on the Selection and Connection Properties communicated by the application, along with any security parameters.  The implementation can only attempt to use multiple Protocol Stacks when they are "equivalent", which means that the stacks can provide the same Transport Properties and interface expectations as requested by the application.  Equivalent Protocol Stacks can be safely swapped or raced in parallel (see racing) during connection establishment. </ins> The following two examples show non-equivalent Protocol Stacks:


This approach is commonly used for connections with optional proxy server configurations.  A single connection might have several options available: an HTTP-based proxy, a SOCKS-based proxy, or no <del> proxy.  These options should be ranked and attempted in succession. </del>  This approach also allows a client to attempt different sets of application and transport protocols that, when available, could

URL I think we should add a similar ranking consideration description as we have for Network paths. Otherwise, I am not sure how to rank the protocol option.
I think here as well that the options should be ranked based on preference, system policy, and performance. I made a pull request to add it.
LGTM, lets of others have any opinion about it..
I agree with NAME
WFM

This approach is commonly used for connections with optional proxy server configurations.  A single connection might have several options available: an HTTP-based proxy, a SOCKS-based proxy, or no  <ins> proxy.  As above, these options should be ranked based on preference, system policy, and performance and attempted in succession. </ins> This approach also allows a client to attempt different sets of application and transport protocols that, when available, could


"WithIPv6Address" with an unscoped address and "WithInterface " together. <del> An Endpoint cannot have multiple identifiers of a same type set. That is, an endpoint cannot have two IP addresses specified.  Two separate IP addresses are represented as two Endpoint Objects.  If a Preconnection specifies a Remote Endpoint with a specific IP address set, it will only establish Connections to that IP address.  If, on the other hand, the Remote Endpoint specifies a hostname but no addresses, the Connection can perform name resolution and attempt using any address derived from the original hostname of the Remote Endpoint.  Note that multiple Remote Endpoints can be added to a Preconnection, as discussed in add-endpoints. </del>  The Transport Services system resolves names internally, when the Initiate(), Listen(), or Rendezvous() method is called to establish a

I'm happy to do this! But while we're at it, isn't the "a" a bit awkward? Wouldn't this read even better as: "An Endpoint MUST NOT be configured with multiple identifiers of the same type." I just pushed that suggestion.
URL This seems to me as a strong claim without using normative language. Shall we use normative language here?
Agree, although then I think we need to explain "set" so that we create an RFC2119 sentence with meaning when read on its own. Is this anywhere near: An Endpoint MUST NOT set multiple identifiers of the same type. And... is the /that is/ correct? or is this an example of something that is not allowed?
I'd say it's an example, although also the most likely such case. Suggest: replace "That is," with "Thus,"
If this is just an example then lets just be explicit about it.
I like the change. Is the English clunky, could it be: An Endpoint MUST NOT be configured with multiple identifiers of a same type.

"WithIPv6Address" with an unscoped address and "WithInterface " together.  <ins> An Endpoint MUST NOT be configured with multiple identifiers of the same type.  For example, an endpoint cannot have two IP addresses specified.  Two separate IP addresses are represented as two Endpoint Objects.  If a Preconnection specifies a Remote Endpoint with a specific IP address set, it will only establish Connections to that IP address.  If, on the other hand, the Remote Endpoint specifies a hostname but no addresses, the Connection can perform name resolution and attempt using any address derived from the original hostname of the Remote Endpoint.  Note that multiple Remote Endpoints can be added to a Preconnection, as discussed in add-endpoints. </ins> The Transport Services system resolves names internally, when the Initiate(), Listen(), or Rendezvous() method is called to establish a


updating maintenance options. Termination (termination) focuses on the methods by which data <del> transmission is stopped, and state is torn down in the transport. </del>  The diagram below provides a high-level view of the actions and events during the lifetime of a Connection object.  Note that some

/transport/ should be /connection state/
This resolves one small part of Zahed's review.
These comments are good to be addressed to improve the document, however, they can be done as part of IETF last call as well
Fixes proposed in PRs , , , ,
LGTM

updating maintenance options. Termination (termination) focuses on the methods by which data  <ins> transmission is stopped, and connection state is torn down. </ins> The diagram below provides a high-level view of the actions and events during the lifetime of a Connection object.  Note that some


4.1.2.  Preconnection: A Preconnection object is a representation of a Connection that has not yet been established.  It has state that describes parameters of the Connection: the Local Endpoint from can also be specified during data transfer to affect specific Messages. <del> Connection: A Connection object represents one or more active transport protocol instances that can send and/or receive Messages between Local and Remote Endpoints.  It is an abstraction that represents the communication.  The Connection object holds state pertaining to the underlying transport protocol instances and any ongoing data transfers.  For example, an active Connection can represent a connection-oriented protocol such as TCP, or can represent a fully-specified 5-tuple for a connectionless protocol such as UDP, where the Connection remains an abstraction at the endpoints.  It can also represent a pool of transport protocol instances, e.g., a set of TCP and QUIC connections to equivalent endpoints, or a stream of a multi-streaming transport protocol instance.  Connections can be created from a Preconnection or by a Listener. </del> Listener: A Listener object accepts incoming transport protocol connections from Remote Endpoints and generates corresponding Connection objects.  It is created from a Preconnection object

Review comment: Section 4.1.2 : I would describe the object first and then the transport properties. In the current arrangement when properties are described it mentions Connection which is described just later. Also transport properties here are kind of repetition of what we have in Section 3.1. reordered descriptions, which also to me at least, seems to make the text on properties better relate to the action
These comments are good to be addressed to improve the document, however, they can be done as part of IETF last call as well
Fixes proposed in PRs , , , ,
LGTM

4.1.2. <ins> Connection: A Connection object represents one or more active transport protocol instances that can send and/or receive Messages between Local and Remote Endpoints.  It is an abstraction that represents the communication.  The Connection object holds state pertaining to the underlying transport protocol instances and any ongoing data transfers.  For example, an active Connection can represent a connection-oriented protocol such as TCP, or can represent a fully-specified 5-tuple for a connectionless protocol such as UDP, where the Connection remains an abstraction at the endpoints.  It can also represent a pool of transport protocol instances, e.g., a set of TCP and QUIC connections to equivalent endpoints, or a stream of a multi-streaming transport protocol instance.  Connections can be created from a Preconnection or by a Listener. </ins> Preconnection: A Preconnection object is a representation of a Connection that has not yet been established.  It has state that describes parameters of the Connection: the Local Endpoint from can also be specified during data transfer to affect specific Messages.  Listener: A Listener object accepts incoming transport protocol connections from Remote Endpoints and generates corresponding Connection objects.  It is created from a Preconnection object


the Remote Endpoint if the transport protocol allows this.  (Note that this is distinct from the concept of "half-closing" a bidirectional connection, such as when a FIN is sent in one <del> direction of a TCP connection ?RFC9293.  The end of a stream can </del>  also be indicated using Message Properties when sending.) Abort: The action the application takes on a Connection to

These comments are good to be addressed to improve the document, however, they can be done as part of IETF last call as well
Fixes proposed in PRs , , , ,
LGTM

the Remote Endpoint if the transport protocol allows this.  (Note that this is distinct from the concept of "half-closing" a bidirectional connection, such as when a FIN is sent in one  <ins> direction of a TCP connection RFC9293.  The end of a stream can </ins> also be indicated using Message Properties when sending.) Abort: The action the application takes on a Connection to


choosing the candidates to be raced, selecting appropriate transport parameters, etc.  An application SHOULD NOT depend on specific caching behaviour, instead it ought to explicitly request <del> any requid or desired properties via the Transport Services API. </del>  4.2.1.

Don't just rely on the cache .
URL I think we should be very specific that the application SHOULD not expect certain caching behavior or MAY expect a minimum set of information cached. This is also related to the expectancy from application to expect same protocol given same properties and security parameter each time. will such input generate same consistent out put from one TAPS system?
I suggest adding this explicitly - something like: This caching does not imply that the same decisions are necessarily made for subsequent connections, rather, it means that cached state is used by the Transport Services architecture to inform functions such as choosing the candidates to be raced, selecting appropriate transport parameters, etc.
See PR on request required properties , which could close this issue.
Thought resolved by merged PR in latest editor version.
NAME Does the merged text in master address issue ?
LGTM, Thansk.
Very nice (IMHO)!

choosing the candidates to be raced, selecting appropriate transport parameters, etc.  An application SHOULD NOT depend on specific caching behaviour, instead it ought to explicitly request  <ins> any required or desired properties via the Transport Services API. </ins> 4.2.1.


notified of the status of its data transfer. Event Handling (events) defines categories of notifications that <del> an application can receive during the lifetime of transport objects.  Events also provide opportunities for the application to interact with the underlying transport by querying state or updating maintenance options. </del>  Termination (termination) focuses on the methods by which data transmission is stopped, and connection state is torn down.

Responding to review and tighter wording for the Arch draft: Undefined "transport object"
URL Where is this transport object defined?

notified of the status of its data transfer. Event Handling (events) defines categories of notifications that  <ins> an application can receive during the lifetime of a Connection. Events also provide opportunities for the application to interact with the underlying transport by querying state or updating maintenance options. </ins> Termination (termination) focuses on the methods by which data transmission is stopped, and connection state is torn down.


identified by concatenating its integer to it's parents identifier with a dot in between, such as "1.1" and "1.2".  Each node will be summarized by a tuple of three elements: endpoint, path (labeled here <del> by interface), and protocol.  The above example can now be written more succinctly as: </del>  When an implementation is asked to establish a single connection, only one of the leaf nodes in the candidate set is needed to transfer

Fixes Issue
URL We have given example but we haven't really defined how the format should be written or how one should interpret in the example. Here "Any Stream" means any protocol that supports streaming ... but it would take quit some time to get to that point . It is also confusing that an "Any" is used with comma (,) and another is without a comma... To understand the example correctly, I suggest we either keep the examples on to a level where this is already described or describe how we are formatting the expression in this document as we described tree structure with numeric ( for example 1 , 1,1 ).
Perhaps we can just write HTTP and Stream without the Any part? Alternatively we could add a specific interface, e.g Wi-Fi, to avoid the first Any. And then also clarify the description of the example and what is raced. The notation is described earlier in the text, so I assume that is not the problem?
If you propose the changes then I can perhaps understand it better about the modified example.
NAME does PR solve the issue for you?
Thanks for the PR. I put two comments as input. I am fine merging it once Tommy's questions are resolved.

identified by concatenating its integer to it's parents identifier with a dot in between, such as "1.1" and "1.2".  Each node will be summarized by a tuple of three elements: endpoint, path (labeled here  <ins> by interface), and protocol.  In protocol stacks, the layers are separated by '/' and ordered top-down.  The above example can now be written more succinctly as: </ins> When an implementation is asked to establish a single connection, only one of the leaf nodes in the candidate set is needed to transfer


4.1.8. <del> A Connection Group is a set of Connections that shares properties and caches.  A Connection Group represents state for managing Connections within a single application, and does not require end-to-end protocol signaling.  For multiplexing transport protocols, only Connections within the same Connection Group are allowed to be multiplexed together. </del>  The API allows a Connection to be created from another Connection. This adds the new Connection to the Connection Group.  A change to of an already active multi-streaming protocol instance. While Connection Groups are managed by the Transport Services system, <del> an application can define Connection Contexts to control caching boundaries, as discussed in conn-context. </del>  4.2.

URL In this section - can we be clear on stating what properties we are taking about and what the caches. see the first line of the section. the second paragraph should at least mention why the connection is cloned. We haven't introduced the cloning before. we need to discuss the relation with Connection Context, does a Connection group have same connection context? My current understanding is if the Connection Context is separate then those Connections wont be grouped. But I fear that this can create confusion.
Latest merged master fixes bullet 2. The others need new text.
LGTM! Many thanks for doing this

4.1.8.  <ins> A Connection Group is a set of Connections that shares Connection Properties and cached state generated by protocols.  A Connection Group represents state for managing Connections within a single application, and does not require end-to-end protocol signaling.  For multiplexing transport protocols, only Connections within the same Connection Group are allowed to be multiplexed together. </ins> The API allows a Connection to be created from another Connection. This adds the new Connection to the Connection Group.  A change to of an already active multi-streaming protocol instance. While Connection Groups are managed by the Transport Services system,  <ins> an application can define different Connection Contexts for different Connection Groups to explicitly control caching boundaries, as discussed in conn-context. </ins> 4.2.


secure protocols to insecure protocols, or to weaker versions of secure protocols (see equivalence).  For example, if an application requests a specific version of TLS, but the desired version of TLS is <del> not available, its connection will fail.  The Transport Services API MAY allow applications to specify minimum versions that are allowed to be used by the Transport Services system. </del>

URL This I believe is already covered in section 3.3. URL why this should not be moved to section 3.3 ?
Any thoughts here?
We did this intentionally to make sure the security considerations had the normative language there. I personally find it OK to have it both places. NAME are you OK with no change?
(We could of course note in one sentence that the requirements for security are provided in the security considerations section).
I added a reference back to 3.3, and made the MAY be a can. So that takes care of the second point. However, the first point with the cert reference I don't think is covered in 3.3, and should remain in security.
NAME
seems like I missed all the call out for me.. this has been strange that I don't get any emails about my mentions and comment's reply. This is only happening in case of TAPS github. anyway, changes are OK with me.
WFMlgtm

secure protocols to insecure protocols, or to weaker versions of secure protocols (see equivalence).  For example, if an application requests a specific version of TLS, but the desired version of TLS is  <ins> not available, its connection will fail.  As described in equivalence, the Transport Services API can allow applications to specify minimum versions that are allowed to be used by the Transport Services system. </ins>


"WithIPv6Address" with an unscoped address and "WithInterface " together. <del> An Endpoint MUST NOT be configured with multiple identifiers of the same type.  For example, an endpoint cannot have two IP addresses specified.  Two separate IP addresses are represented as two Endpoint Objects.  If a Preconnection specifies a Remote Endpoint with a specific IP address set, it will only establish Connections to that IP address.  If, on the other hand, the Remote Endpoint specifies a hostname but no addresses, the Connection can perform name resolution and attempt using any address derived from the original hostname of the Remote Endpoint.  Note that multiple Remote Endpoints can be added to a Preconnection, as discussed in add-endpoints. </del>  The Transport Services system resolves names internally, when the Initiate(), Listen(), or Rendezvous() method is called to establish a connections, rather, it means that cached state is used by the Transport Services architecture to inform functions such as choosing the candidates to be raced, selecting appropriate <del> transport parameters, etc.  An application SHOULD NOT depend on </del>  specific caching behaviour, instead it ought to explicitly request any required or desired properties via the Transport Services API.

According to: URL As a small change to Gorry's second proposal, this uses: "The design of the API MUST NOT permit an Endpoint to be configured with multiple identifiers of the same type." instead of: "The design of the API MUST NOT permit an Endpoint to set multiple identifiers of the same type." because it's not the Endpoint itself that is actually doing anything.
looks fine to me On 14/03/2023 10:24, Mirja Kuehlewind wrote: I'm unsure that I precisely understand the diference between /rely upon/ and /depend upon/, in this sentence I'd be happy either with either word "rely" would be fine for me. I think (if I understand your argument) that you say a design will prevent this because that is how we define Endpoint. I'd agree a design of system cannot allow this, but then thenis it any better to state the design requirement as "The design of the API MUST NOT permit an Endpoint to set multiple identifiers of the same type." Gorry

"WithIPv6Address" with an unscoped address and "WithInterface " together.  <ins> The design of the API MUST NOT permit an Endpoint to be configured with multiple identifiers of the same type.  For example, an endpoint cannot have two IP addresses specified.  Two separate IP addresses are represented as two Endpoint Objects.  If a Preconnection specifies a Remote Endpoint with a specific IP address set, it will only establish Connections to that IP address.  If, on the other hand, the Remote Endpoint specifies a hostname but no addresses, the Connection can perform name resolution and attempt using any address derived from the original hostname of the Remote Endpoint.  Note that multiple Remote Endpoints can be added to a Preconnection, as discussed in add-endpoints. </ins> The Transport Services system resolves names internally, when the Initiate(), Listen(), or Rendezvous() method is called to establish a connections, rather, it means that cached state is used by the Transport Services architecture to inform functions such as choosing the candidates to be raced, selecting appropriate  <ins> transport parameters, etc.  An application SHOULD NOT rely on </ins> specific caching behaviour, instead it ought to explicitly request any required or desired properties via the Transport Services API.


In the following sections, we describe the details of application interaction with Objects through Actions and Events in each phase of <del> a connection, following the phases described in TAPS-ARCH.  An example interface sketch in Go is shown in appendix-api-sketch. </del>  5. any time by using the following call on the Connection object: Note that most properties are only considered for connection <del> establishment and can not be changed later on. appendix-specify- query-params gives an overview of what Transport Parameters can be specified and queried during which phase. </del>  A Connection gets its Transport Parameters either by being explicitly configured via a Preconnection, or by inheriting them from an with the Transport Parameters (see transport-params).  This allows to specify Protocol Properties and that can be overridden on a per- Message basis or Application Intents that apply to a specific <del> Message.  See appendix-specify-query-params for an overview. </del>  Send Parameters may be inconsistent with the properties of the Protocol Stacks underlying the Connection on which a given Message is correspond to the properties given in transport-params and can only be queried. <del> Transport Features of the protocols that were selected, once the Connection has been established.  These features correspond to the properties given in transport-params and can only be queried. </del>  Protocol Properties of the Protocol Stack in use (see protocol- props below).  These can be set or queried.  Certain specific <del> procotol queries may be read-only, on a protocol and property </del>  specific basis. Path Properties of the path(s) in use, once the Connection has provisioning domain, measurements by the protocol stack, or other sources.  They can only be queried. <del> appendix-specify-query-params gives a more detailed overview of the different types of properties that can be set and queried at different times. </del> 9.1. Protocol Properties represent the configuration of the selected

Appendix B of the API draft provides a sample concrete definition of the API, written in Go. Having concrete examples of the API is clearly useful, but I question whether this draft is the right place for them, since we don't want to bless a particular API variant. Suggest this appendix be moved to either the implementation draft, or a separate example API implementation draft.
The intention here is to show that the API is reasonably expressible and expressive in at least one modern language. I'd be more than happy to replace it with links to the code and documentation for now though. (Eventually, examples would be more useful than the sketch though.)
NAME makes sense.
Looks good to me.Looks good to me

In the following sections, we describe the details of application interaction with Objects through Actions and Events in each phase of  <ins> a connection, following the phases described in TAPS-ARCH. </ins> 5. any time by using the following call on the Connection object: Note that most properties are only considered for connection  <ins> establishment and can not be changed after a connection is established; however, they can be queried.  See introspection. </ins> A Connection gets its Transport Parameters either by being explicitly configured via a Preconnection, or by inheriting them from an with the Transport Parameters (see transport-params).  This allows to specify Protocol Properties and that can be overridden on a per- Message basis or Application Intents that apply to a specific  <ins> Message. </ins> Send Parameters may be inconsistent with the properties of the Protocol Stacks underlying the Connection on which a given Message is correspond to the properties given in transport-params and can only be queried.  <ins> Transport Features of the protocol stacks that were selected and instantiated, once the Connection has been established.  These features correspond to the properties given in transport-params and can only be queried.  Instead of preference levels, these features have boolean values indicating whether or not they were selected.  Note that these transport features may not fully reflect the specified parameters given in the pre-establishment phase.  For example, a certain Protocol Selection Property that an application specified as Preferred may not actually be present in the chosen Protocol Stack Instances because none of the currently available transport protocols had this feature. </ins> Protocol Properties of the Protocol Stack in use (see protocol- props below).  These can be set or queried.  Certain specific  <ins> procotol queries may be read-only, on a protocol- and property- </ins> specific basis. Path Properties of the path(s) in use, once the Connection has provisioning domain, measurements by the protocol stack, or other sources.  They can only be queried.  9.1. Protocol Properties represent the configuration of the selected


Connections into a Connection Group over a single flow.  This is not a strict requirement.  The default is to not have this option. <del> Suggest a timeout to the Remote Endpoint: This boolean property specifies whether an application considers it useful to propose a timeout until the connection is assumed to be lost.  This property applies to Connections and Connection Groups.  This is not a strict requirement.  The default is to have this option. </del> Notification of special errors (excessive retransmissions, ICMP error message arrival): This boolean property specifies whether an application considers it useful to be informed in case sent data establishment, or before deciding that a connection has failed after establishment.  It is given in seconds. <del> Abort timeout to suggest to the Remote Endpoint: This numeric property specifies the timeout to propose to the Remote Endpoint. It is given in seconds. </del> Retransmission threshold before excessive retransmission notification: This numeric property specifies after how many retransmissions to inform the application about "Excessive

This API says: Need to clarify if this is a timeout for connection establishment (i.e., how long should the endpoint wait before declaring that failed), or it it's a timeout for data transfer after a connection has been established?
Before you do Initiate, it's the timeout for establishment. After the connection has been established, it's the timeout for data transfer. It was my idea that one notion of a timeout is enough - you will never need both in parallel for the same Connection or Preconnection.
Those seem like two very different timeouts, and ones for which the application may have very different tolerances. Personally, I’ve been averse to giving timeout knobs in general, since choosing good timeouts is hard, and a knob makes developers think they need to turn it. Most of the time, no timeout is best (talk to Stuart). Beyond that, any establishment or receive timeout can just as easily be implemented in the application as they wait for their Ready or Receive Complete event. This knob is a convenience to re-arm a timer, not really a transport service itself.
Move to Appendix A, then?
I agree that these timeout values may be quite different; maybe merging them into only one parameter wasn't a good idea. About this: Let me try to understand this: do you mean to say that the TCP User Timeout should simply be set to a huge number, large enough to basically never fire, and then it's up to the application to decide when to give up? I'd have to think about this... note that this comes via the TCP RFCs => RFC 8303 => minset path, it's not my invention.
NAME I'm not arguing against TCP having a timeout option, but the discussion of this option in the API—especially as a one top-level, cross protocol, all-encompassing timeout—was going in a direction of adding timeouts where we wouldn't otherwise have them. If we had a timeout on overall connection establishment, from Initiate() to Ready(), then that's trying to set a timeout not just on TCP, but on DNS, racing, proxies, TLS, and who knows what else. I tend to see the timeout value as a specific protocol option if anything; sure, you can set a timer on any protocol you want, but is that really a benefit to the application? If a protocol behaves differently than TCP in the future with regards to how it acknowledges data, should setting the TCP User Timeout for how long data can be un-acked apply to this future transport, or are we starting to ossify it?
NAME : first, I didn't think about the timeout being so all-encompassing (DNS, racing, etc.) - but you're right, the way we have it, it becomes like that, and this sure sounds like a horrible idea. So I agree that this should only be a specific protocol option if anything. Regarding "if anything", I understand your arguments and tend to agree with them, too. However, I'm just a little careful about things coming from minset - I think that we must have sound arguments to remove them, of the style "functionality XY covers this, and it can be dealt with inside the transport system because ...". After all, the UTO exists for a reason... Noticing your thumb up for NAME 's suggestion to move this to appendix A, I think we're all in agreement on this approach for now.
Yeah, totally fine with this being in Appendix A for now. Definitely merits more discussion.
see
(mutating this issue to be the place to discuss these options)
It seems we must discuss this more for a different type of timeout. Right now, we have, as the only generic thing: "Timeout for aborting Connection". The description says: "This property specifies how long to wait before aborting a Connection during establishment, or before deciding that a Connection has failed after establishment." The "during establishment" part is awkward: as NAME said above, these are quite different timeouts, where the application may have different tolerances. From minset (see appendix C), we need to support: "Specify number of attempts and/or timeout for the first establishment message:" ... and it seems to me to be a reasonable thing to add - sure, the default should be large enough for all these fun types of racing to take place, but if an application is very intolerant of waiting to get a connection, it should be able to say so, right? So my proposal is to remove the "during establishment" text from "Timeout for aborting Connection", and add "Timeout for aborting Connection establishment" (I think number of attempts isn't necessary and just gets silly as a generic thing when we're in fact trying multiple interfaces and protocols), with the description "This property specifies how long to wait before aborting a Connection during establishment."
Suggest adding a reference to the GitHub issue in the appendix, along with the text, to remind us that there's more to do here. Otherwise looks good.

Connections into a Connection Group over a single flow.  This is not a strict requirement.  The default is to not have this option.  Notification of special errors (excessive retransmissions, ICMP error message arrival): This boolean property specifies whether an application considers it useful to be informed in case sent data establishment, or before deciding that a connection has failed after establishment.  It is given in seconds.  Retransmission threshold before excessive retransmission notification: This numeric property specifies after how many retransmissions to inform the application about "Excessive


multiple times.  See also send-idempotent.  This is a strict requirement.  The default is to not have this option. <del> Efficient use of Connection Groups: This boolean property specifies whether an application considers it useful to create Connection Groups, e.g. to explicitly prioritize between Connections within a Connection Group.  This property will tend to select multistreaming transport protocols, which can multiplex Connections into a Connection Group over a single flow.  This is not a strict requirement.  The default is to not have this option. </del>  Notification of special errors (excessive retransmissions, ICMP error message arrival): This boolean property specifies whether an each such Connection must be established separately.  Changes to the parameters of a Preconnection entangled with a Preconnection from which a Connection has already been established will fail.  Calling <del> Clone on a Preconnection may be taken by the system an implicit sign that protocol stacks supporting efficient connection group usage are preferred by the application. </del>  There is only one Protocol Property that is not entangled, i.e., it is a separate per-Connection Property for individual Connections in

The API document says: I'm not sure I follow this. The text doesn't seem to match the option name: it isn't saying use connection groups efficiently or not, it's specifying whether connection groups can be used at all. It's also not clear why prioritisation is given as an example. Would it be clearer written something more like the following?
yep. Although you still have to explicitly entangle connections by cloning them if you want them to be guaranteed to be within a connection group.
URL makes me question why we need this parameter?
To explicitly prefer multistreaming protocols during selection, because you wrote your app to clone connections instead of cloning preconnections.
(see )

multiple times.  See also send-idempotent.  This is a strict requirement.  The default is to not have this option.  <ins> Multiplex connections: This boolean property specifies that the application would prefer multiple Connections between the same endpoints within a Connection Group to be multiplexed onto a single underlying transport connection where possible, for reasons of efficiency.  This is not a strict requirement.  The default is to not have this option. </ins> Notification of special errors (excessive retransmissions, ICMP error message arrival): This boolean property specifies whether an each such Connection must be established separately.  Changes to the parameters of a Preconnection entangled with a Preconnection from which a Connection has already been established will fail.  Calling  <ins> Clone on a Preconnection may be taken by the system an implicit signal that protocol stacks supporting multiplexed connections for efficient connection grouping are preferred by the application. </ins> There is only one Protocol Property that is not entangled, i.e., it is a separate per-Connection Property for individual Connections in


The application expects to send/receive data at a constant rate after connection establishment.  Delay and delay variation should be optimized at the expense of bandwidth efficiency.  The application is not interactive.  It expects to send/receive a large amount of data, without any urgency.  This can be used

For the Constant Rate capacity profile, should we state that this implies that the connection will fail if there is insufficient capacity? (i.e., you're requesting a circuit breaker rather than congestion control)
may fail instead of will fail, but yeah, this seems sensible.
lgtm

The application expects to send/receive data at a constant rate after connection establishment.  Delay and delay variation should be optimized at the expense of bandwidth efficiency. <ins> This implies that the Connection may fail if the desired rate cannot be maintained across the Path.  A transport may interpret this capacity profile as preferring a circuit breaker RFC8084 to a rate adaptive congestion controller. </ins> The application is not interactive.  It expects to send/receive a large amount of data, without any urgency.  This can be used


Connection Groups.  This is not a strict requirement.  The default is to have this option. <del> Notification of ICMP error message arrival: This boolean property specifies whether an application considers it useful to be informed when an ICMP error message arrives.  This property applies to Connections and Connection Groups.  This is not a strict requirement.  The default is to have this option. </del>  Control checksum coverage on sending or receiving: This boolean property specifies whether the application considers it useful to aborted the Connection; however, there is no guarantee that an abort will be signaled:  11. RFC-EDITOR: Please remove this section before publication.

TEXT: informed when an ICMP error message arrives. I think this is OK. but is this intended to be for soft-errors, since hard-errors break the connection? I think I get this, although some transports obvioulsy "eat" the ICMP packets they receive, and many ICMP messages have no meaning to an app, but some can be important. Tell me more please...
this comes from minset - and so it’s based on the rfc “soft error” text. true, no guarantee that you get it.
So, maybe the next rev of text should just say this and it will be fine.

Connection Groups.  This is not a strict requirement.  The default is to have this option.  <ins> Notification of ICMP soft error message arrival: This boolean property specifies whether an application considers it useful to be informed when an ICMP error message arrives that does not force termination of a connection.  This property applies to Connections and Connection Groups.  Received ICMP errors will be available as SoftErrors.  Note that even if a protocol supporting this property is selected, not all ICMP errors will necessarily be delivered, so applications cannot rely on receiving them.  This is not a strict requirement.  The default is not to have this option. </ins> Control checksum coverage on sending or receiving: This boolean property specifies whether the application considers it useful to aborted the Connection; however, there is no guarantee that an abort will be signaled: <ins> A SoftError can inform the application about the receipt of an ICMP error message that does not force termination of the connection, if the underlying protocol stack supports access to soft errors; however, even if the underlying stack supports it, there is no guarantee that a soft error will be signaled. </ins> 11. RFC-EDITOR: Please remove this section before publication.


over TCP.  An alternate set of default Protocol Selection Properties would represent a configuration that can be implemented over UDP. <del> The following properties can be used during Protocol and Path selection: Reliable Data Transfer: This boolean property specifies whether the application wishes to use a transport protocol that that provides mechanisms to help ensure that all data is received and without corruption on the other side.  This also entails being notified when a Connection is closed or aborted.  This property applies to Connections and Connection Groups.  This is a strict requirement.  The default is to enable Reliable Data Transfer. Preservation of data ordering: This boolean property specifies whether the application wishes to use a transport protocol that provides mechanisms to ensure that data is received by the application on the other end in the same order as it was sent. This property applies to Connections and Connection Groups.  This is a strict requirement.  The default is to preserve data ordering. Configure reliability on a per-Message basis: This boolean property specifies whether an application considers it useful to indicate its reliability requirements on a per-Message basis. This property applies to Connections and Connection Groups.  This is not a strict requirement.  The default is to not have this option. Use 0-RTT session establishment with an idempotent Message: This boolean property specifies whether an application would like to supply a Message to the transport protocol before Connection establishment, which will then be reliably transferred to the other side before or during Connection establishment, potentially multiple times.  See also send-idempotent.  This is a strict requirement.  The default is to not have this option. Multistream Connections in Group: This boolean property specifies that the application would prefer multiple Connections within a Connection Group to be provided by streams of a single underlying transport connection where possible.  This is not a strict requirement.  The default is to not have this option. Notification of excessive retransmissions: This boolean property specifies whether an application considers it useful to be informed in case sent data was retransmitted more often than a certain threshold.  This property applies to Connections and Connection Groups.  This is not a strict requirement.  The default is to have this option. Notification of ICMP soft error message arrival: This boolean property specifies whether an application considers it useful to be informed when an ICMP error message arrives that does not force termination of a connection.  This property applies to Connections and Connection Groups.  Received ICMP errors will be available as SoftErrors.  Note that even if a protocol supporting this property is selected, not all ICMP errors will necessarily be delivered, so applications cannot rely on receiving them.  This is not a strict requirement.  The default is not to have this option. Control checksum coverage on sending or receiving: This boolean property specifies whether the application considers it useful to enable / disable / configure a checksum when sending data, or decide whether to require a checksum or not when receiving data. This property applies to Connections and Connection Groups.  This is not a strict requirement, as it signifies a reduction in reliability.  The default is full checksum coverage without being able to change it, and requiring a checksum when receiving. Interface Type: This enumerated property specifies which kind of access network interface, e.g., WiFi, Ethernet, or LTE, to prefer over others for this Connection, in case they are available.  In general, Interface Types should be used only with the "Prefer" and "Prohibit" preference level.  Specifically, using the "Require" preference level for Interface Type may limit path selection in a way that is detrimental to connectivity.  The default is to use the default interface configured in the system policy. Capacity Profile: This enumerated property specifies the application's expectation of the dominating traffic pattern for this Connection.  The Capacity Profile should only be used with the "Prefer" preference level; other preference levels make no sense for profiles.  The following values are valid for Capacity Profile: The application makes no representation about its expected capacity profile.  No special optimizations of the tradeoff between delay, delay variation, and bandwidth efficiency should be made when selecting and configuring stacks. The application is interactive.  Response time (latency) should be optimized at the expense of bandwidth efficiency and delay variation.  This can be used by the system to disable the coalescing of multiple small Messages into larger packets (Nagle's algorithm), to prefer lower-latency paths, signal a preference for lower-latency, higher-loss treatment, and so on. The application expects to send/receive data at a constant rate after Connection establishment.  Delay and delay variation should be optimized at the expense of bandwidth efficiency. This implies that the Connection may fail if the desired rate cannot be maintained across the Path.  A transport may interpret this capacity profile as preferring a circuit breaker RFC8084 to a rate adaptive congestion controller. The application is not interactive.  It expects to send/receive a large amount of data, without any urgency.  This can be used to select protocol stacks with scavenger transmission control, to signal a preference for less-than-best-effort treatment, and so on. In addition to protocol and path selection properties, the transport parameters may also contain Generic and/or Specific Protocol Properties (see protocol-props).  These properties will be passed to the selected candidate Protocol Stack(s) to configure them before candidate Connection establishment. 5.2.1. </del> All transport parameters used in the pre-establishment phase are collected in a TransportParameters Object that is passed to the Preconnection Object. configured via a Preconnection, or by inheriting them from an antecedent via cloning; see groups for more.  5.3. Common parameters such as TLS ciphersuites are known to This enumerated property specifies the application's preferred tradeoffs for sending this Message; it is a per-Message override of <del> the Capacity Profile protocol and path selection property (see transport-params). </del>  The following values are valid for Instantaneous Capacity Profile:

Send parameters were subsections, transport selection properties were not. This fixes that by promiting transport selection properties to subsections, and reorganizing the sections slightly to make that fit. There are no changes to technical content in this PR.
Makes sense - had that one also on my list of ugliness to be fixed.

over TCP.  An alternate set of default Protocol Selection Properties would represent a configuration that can be implemented over UDP.  All transport parameters used in the pre-establishment phase are collected in a TransportParameters Object that is passed to the Preconnection Object. configured via a Preconnection, or by inheriting them from an antecedent via cloning; see groups for more. <ins> In addition to protocol and path selection properties, the transport parameters may also contain Generic and/or Specific Protocol Properties (see protocol-props).  These properties will be passed to the selected candidate Protocol Stack(s) to configure them before candidate Connection establishment. The following properties can be used during Protocol and Path selection: 5.2.1. This boolean property specifies whether the application wishes to use a transport protocol that that provides mechanisms to help ensure that all data is received and without corruption on the other side. This also entails being notified when a Connection is closed or aborted.  This property applies to Connections and Connection Groups. This is a strict requirement.  The default is to enable Reliable Data Transfer. 5.2.2. This boolean property specifies whether the application wishes to use a transport protocol that provides mechanisms to ensure that data is received by the application on the other end in the same order as it was sent.  This property applies to Connections and Connection Groups.  This is a strict requirement.  The default is to preserve data ordering. 5.2.3. This boolean property specifies whether an application considers it useful to indicate its reliability requirements on a per-Message basis.  This property applies to Connections and Connection Groups. This is not a strict requirement.  The default is to not have this option. 5.2.4. This boolean property specifies whether an application would like to supply a Message to the transport protocol before Connection establishment, which will then be reliably transferred to the other side before or during Connection establishment, potentially multiple times.  See also send-idempotent.  This is a strict requirement.  The default is to not have this option. 5.2.5. This boolean property specifies that the application would prefer multiple Connections within a Connection Group to be provided by streams of a single underlying transport connection where possible. This is not a strict requirement.  The default is to not have this option. 5.2.6. This boolean property specifies whether an application considers it useful to be informed in case sent data was retransmitted more often than a certain threshold.  This property applies to Connections and Connection Groups.  This is not a strict requirement.  The default is to have this option. 5.2.7. This boolean property specifies whether an application considers it useful to be informed when an ICMP error message arrives that does not force termination of a connection.  This property applies to Connections and Connection Groups.  Received ICMP errors will be available as SoftErrors.  Note that even if a protocol supporting this property is selected, not all ICMP errors will necessarily be delivered, so applications cannot rely on receiving them.  This is not a strict requirement.  The default is not to have this option. 5.2.8. This boolean property specifies whether the application considers it useful to enable / disable / configure a checksum when sending data, or decide whether to require a checksum or not when receiving data. This property applies to Connections and Connection Groups.  This is not a strict requirement, as it signifies a reduction in reliability. The default is full checksum coverage without being able to change it, and requiring a checksum when receiving. 5.2.9. This enumerated property specifies which kind of access network interface, e.g., WiFi, Ethernet, or LTE, to prefer over others for this Connection, in case they are available.  In general, Interface Types should be used only with the "Prefer" and "Prohibit" preference level.  Specifically, using the "Require" preference level for Interface Type may limit path selection in a way that is detrimental to connectivity.  The default is to use the default interface configured in the system policy. 5.2.10. This enumerated property specifies the application's expectation of the dominating traffic pattern for this Connection.  The Capacity Profile should only be used with the "Prefer" preference level; other preference levels make no sense for profiles.  The following values are valid for Capacity Profile: The application makes no representation about its expected capacity profile.  No special optimizations of the tradeoff between delay, delay variation, and bandwidth efficiency should be made when selecting and configuring stacks. The application is interactive.  Response time (latency) should be optimized at the expense of bandwidth efficiency and delay variation.  This can be used by the system to disable the coalescing of multiple small Messages into larger packets (Nagle's algorithm), to prefer lower-latency paths, signal a preference for lower-latency, higher-loss treatment, and so on. The application expects to send/receive data at a constant rate after Connection establishment.  Delay and delay variation should be optimized at the expense of bandwidth efficiency.  This implies that the Connection may fail if the desired rate cannot be maintained across the Path.  A transport may interpret this capacity profile as preferring a circuit breaker RFC8084 to a rate adaptive congestion controller. The application is not interactive.  It expects to send/receive a large amount of data, without any urgency.  This can be used to select protocol stacks with scavenger transmission control, to signal a preference for less-than-best-effort treatment, and so on. </ins> 5.3. Common parameters such as TLS ciphersuites are known to This enumerated property specifies the application's preferred tradeoffs for sending this Message; it is a per-Message override of  <ins> the Capacity Profile protocol and path selection property (see prop- cap-profile). </ins> The following values are valid for Instantaneous Capacity Profile:


between delay, delay variation, and bandwidth efficiency should be made when selecting and configuring stacks. <del> The application is interactive.  Response time (latency) should be optimized at the expense of bandwidth efficiency and delay variation.  This can be used by the system to disable the coalescing of multiple small Messages into larger packets (Nagle's algorithm), to prefer lower-latency paths, signal a preference for lower-latency, higher-loss treatment, and so on. </del>  The application expects to send/receive data at a constant rate after Connection establishment.  Delay and delay variation should <del> be optimized at the expense of bandwidth efficiency.  This implies </del>  that the Connection may fail if the desired rate cannot be maintained across the Path.  A transport may interpret this capacity profile as preferring a circuit breaker RFC8084 to a rate 7.1.6. <del> This boolean property specifies, if true, that an application wants this Message to be acknowledged immediately by the receiver.  In case of reliable transmission, this informs the transport protocol on the sender side faster that it can remove the Message from its buffer; therefore this property can be useful for latency-critical applications that maintain tight control over the send buffer (see sending). 7.1.7. </del> This enumerated property specifies the application's preferred tradeoffs for sending this Message; it is a per-Message override of the Capacity Profile protocol and path selection property (see prop- cap-profile). <del> The following values are valid for Instantaneous Capacity Profile: </del>  No special optimizations of the tradeoff between delay, delay variation, and bandwidth efficiency should be made when sending bandwidth efficiency and delay variation when sending this message.  This can be used by the system to disable the coalescing of multiple small Messages into larger packets (Nagle's <del> algorithm), to signal a preference for lower-latency, higher-loss treatment, and so on. </del>  <del> Delay and delay variation should be optimized at the expense of </del>  bandwidth efficiency. This Message may be sent at the system's leisure.  This can be

Removes Immediate Acknowledgment and makes it an optional implicit feature of Low Latency profile, renames Instantaneous Capacity Profile to Transmission Profile. Addresses ; we should open a new issue to discuss whether we want to split Capacity Profile back out.
About "Transmission profile", I like it; we had Capacity Profile (not "Instantaneous" though) in NEAT because it contains choices about how an application wants to make use of the available capacity. Because "Transmission profile" loses that hint, it conveys less meaning - but frankly, I still prefer it just for the way it sounds.

between delay, delay variation, and bandwidth efficiency should be made when selecting and configuring stacks.  <ins> Response time (latency) should be optimized at the expense of bandwidth efficiency and delay variation when sending this message.  This can be used by the system to disable the coalescing of multiple small Messages into larger packets (Nagle's algorithm); to prefer immediate acknowledgment from the peer endpoint when supported by the underlying transport; to signal a preference for lower-latency, higher-loss treatment; and so on. </ins> The application expects to send/receive data at a constant rate after Connection establishment.  Delay and delay variation should  <ins> be minimized at the expense of bandwidth efficiency.  This implies </ins> that the Connection may fail if the desired rate cannot be maintained across the Path.  A transport may interpret this capacity profile as preferring a circuit breaker RFC8084 to a rate 7.1.6.  This enumerated property specifies the application's preferred tradeoffs for sending this Message; it is a per-Message override of the Capacity Profile protocol and path selection property (see prop- cap-profile).  <ins> The following values are valid for Transmission Profile: </ins> No special optimizations of the tradeoff between delay, delay variation, and bandwidth efficiency should be made when sending bandwidth efficiency and delay variation when sending this message.  This can be used by the system to disable the coalescing of multiple small Messages into larger packets (Nagle's  <ins> algorithm); to prefer immediate acknowledgment from the peer endpoint when supported by the underlying transport; to signal a preference for lower-latency, higher-loss treatment; and so on. </ins>  <ins> Delay and delay variation should be minimized at the expense of </ins> bandwidth efficiency. This Message may be sent at the system's leisure.  This can be


The names and functions between these APIs are not consistent, and vary depending on the protocol being used.  For example, sending and receiving on a stream of data is conceptually the same between <del> operating on an unencrypted TCP stream and operating on an encrypted TLS stream over TCP, but applications cannot use the same socket send() and recv() calls on top of both kinds of connections. Similarly, terminology for the implementation of protocols offering transport services vary based on the context of the protocols themselves.  This variety can lead to confusion when trying to understand the similarities and differences between protocols, and how applications can use them effectively. </del>  The goal of the Transport Services architecture is to provide a common, flexible, and reusable interface for transport protocols.  As and functional characteristics, and it can communicate with different Remote Endpoints to optimize performance.  Beyond these, if the API for the system remains the same over time, new protocols and features <del> may be added to the system's implementation without requiring significant changes in applications for adoption. </del>  The following considerations were used in the design of this architecture. interface.  Each provided interface mimics an existing protocol- specific interface provided by supported security protocols.  For example, trust verification callbacks are common parts of TLS APIs. <del> Transport Services APIs will expose similar functionality.  Clients must take care to use security APIs appropriately.  In cases where clients use said interface to provide sensitive keying material, e.g., access to private keys or copies of pre-shared keys (PSKs), key use must be validated.  For example, clients should not use PSK material created for ESP with IETF-QUIC, and clients must not use private keys intended for server authentication as a key for client </del>  authentication.  Moreover, unlike certain transport features such as <del> TFO or ECN which can fall back to standard configurations, Transport </del>  Services systems must not permit fallback for security protocols. For example, if a client requests TLS, yet TLS or the desired version are not available, its connection must fail.  Clients are responsible

seeing no comment... :)
Sorry, looks good =) Busy week over here!
See thread at URL Suggested resolution: implementation must have a deterministic tiebreaker, current recommendation is that path properties take precedence. API should note expected behavior. There should be additional text on candidate selection and ordering.
Give example for path candidate gathering and sorting (get selection properties, get available paths in system preferred order, walk through them cancelling out the prohibited ones, and ranking preferences; get ultimate list). Do the same for protocols likely.
Added text to API and Implementation drafts on branch "conflicting-policies". API has an example, implementation still needs one. Feel free to add, otherwise I'll come back to it later today or tomorrow.
I guess that works for -00 For -01, we might want to integrate the resolution a little bit more into the decision process.
Resolved by PR
The Sec Con section contains a large number of unexpanded abbreviations. Compared to the remainder of the document this requires much more knowledge of these terms, suggest we expand them here.
The sentence reads: Beyond these, if the API for the system remains the same over time, new protocols and features may be added to the system's implementation without requiring significant changes in applications for adoption. However, this kind of suggests that some small change is needed to apps. That's not necessarilly true, and I think the key point is the converse (i.e, 3.1 below). Can I suggest: Beyond these, if the API for the system remains the same over time, new protocols and features may be added to the system's implementation without requiring changes in applications for adoption. Hi, I made this comment in the past in QUIC when discussing migration. One policy may be prefer wifi over cellular network, Second policy prefers quic cove TCP Now I walk into my house and my cellphone has HTTP over QUIC. At home will switch to wifi but quic is not supported on the wifi so will fall back to TCP. This contradicts the second policy. So two options wifi TCP or cellular QUIC , how to decide? Roni Even

The names and functions between these APIs are not consistent, and vary depending on the protocol being used.  For example, sending and receiving on a stream of data is conceptually the same between  <ins> operating on an unencrypted Transmission Control Protocol (TCP) stream and operating on an encrypted Transport Layer Security (TLS) I-D.ietf-tls-tls13 stream over TCP, but applications cannot use the same socket send() and recv() calls on top of both kinds of connections.  Similarly, terminology for the implementation of protocols offering transport services vary based on the context of the protocols themselves.  This variety can lead to confusion when trying to understand the similarities and differences between protocols, and how applications can use them effectively. </ins> The goal of the Transport Services architecture is to provide a common, flexible, and reusable interface for transport protocols.  As and functional characteristics, and it can communicate with different Remote Endpoints to optimize performance.  Beyond these, if the API for the system remains the same over time, new protocols and features  <ins> may be added to the system's implementation without requiring changes in applications for adoption. </ins> The following considerations were used in the design of this architecture. interface.  Each provided interface mimics an existing protocol- specific interface provided by supported security protocols.  For example, trust verification callbacks are common parts of TLS APIs.  <ins> Transport Services APIs will expose similar functionality. Clients must take care to use security APIs appropriately.  In cases where clients use said interface to provide sensitive keying material, e.g., access to private keys or copies of pre-shared keys (PSKs), key use must be validated.  For example, clients should not use PSK material created for the Encapsulating Security Protocol (ESP, part of IPsec) RFC4303 with QUIC, and clients must not use private keys intended for server authentication as a keys for client </ins> authentication.  Moreover, unlike certain transport features such as  <ins> TCP Fast Open (TFO) RFC7413 or Explicit Congestion Notification (ECN) RFC3168 which can fall back to standard configurations, Transport </ins> Services systems must not permit fallback for security protocols. For example, if a client requests TLS, yet TLS or the desired version are not available, its connection must fail.  Clients are responsible