Change:
Having read -05, I have some more comments, mostly editorial. Opening an issue in case there's anything to discuss. Otherwise I might just do a PR against -arch if that's fine with the authors. In Section 4.1.1: "Event Handling (Section 4.1.5) defines the set of properties about which an application can receive notifications during the lifetime of transport objects." Set of properties? Section 4.1.5 do not refer to specific properties (as in: Transport Properties), but just lists what kinds of events exist. So I suggest changing text in Section 4.1.1 to say something like: "Event Handling (Section 4.1.5) defines categories of notifications which an application can receive during the lifetime of transport objects." In Section 4.1.4: "When receiving Messages, Message Properties can contain per-protocol properties for properties that are sent between the endpoints." Why is this constrained to properties that are sent between endpoints? Couldn't an implementation also set Message Properties that were not signaled? Also, what does "per-protocol" mean here? Also, too many "properties" in this sentence. I suggest changing this to something like: "When receiving Messages, Message Properties can contain information about the received message, such as signalled by the other endpoint." Still Section 4.1.4: "The status of the Send operation can be delivered back to the sending application in an event" Can be? I thought this always happens? The API draft in Section 7.3 says that for each Send(), the application gets exactly one event? So I think here this should be phrased as "is delivered" or even MUST. Section 4.1.5: "This section provides the top-level categories of events events that can be delivered to an application." Top-level categories? Are there more levels of categories? Maybe just say "categories"? Also, duplicate word: "events events". Section 4.2.1: "Protocol Selection: […] choosing one or more sets of protocol options" I don't think protocol options is the right word. Isn't this about racing protocol stacks? Below we use "protocol options" to mean something else, so here we should just say "choosing between multiple protocol stacks". "separate DNS resolution stepss" (typo) Section 6: "Clients need to ensure that security APIs are used appropriately." Who or what is a client? An application? Or the transport system itself? I think it's an application. "Clients" is not used elsewhere in the text. So this section should replace "clients" with "applications".
All suggestions here are good, please send a PR. I'd rephrase the following: "When receiving Messages, Message Properties can contain information about the received message, such as signalled by the other endpoint." to "When receiving Messages, Message Properties can contain information about the received message, such as metadata generated at the receiver and information signalled by the remote endpoint" ("such as" needs a noun, and I'd like to be more explicit here)

Discussion:
required to send and receive that data, and how the application is notified of the status of its data transfer. <del> Event Handling (events) defines the set of properties about which an application can receive notifications during the lifetime of transport objects.  Events MAY also provide opportunities for the </del> <ins> Event Handling (events) defines categories of notifications which an application can receive during the lifetime of transport objects.  Events MAY also provide opportunities for the </ins> application to interact with the underlying transport by querying state or updating maintenance options.

that specific protocols encode and communicate to the Remote Endpoint.  Message Properties MAY be set on a Preconnection to define default properties for sending.  When receiving Messages, <del> Message Properties can contain per-protocol properties for properties that are sent between the endpoints. </del> <ins> Message Properties can contain information about the received Message, such as metadata generated at the receiver and information signalled by the remote endpoint. </ins> Send: The action to transmit a Message or partial Message over a Connection to the remote system.  The interface to Send MAY include Message Properties specific to how the Message content is <del> to be sent.  The status of the Send operation can be delivered </del> <ins> to be sent.  The status of the Send operation MUST be delivered </ins> back to the sending application in an event (events). Receive: An action that indicates that the application is ready to

4.1.5. <del> This section provides the top-level categories of events that can be delivered to an application.  This list is not exhaustive. </del> <ins> This section provides the categories of events that can be delivered to an application.  This list is not exhaustive. </ins> Connection Ready: Signals to an application that a given Connection is ready to send and/or receive Messages.  If the

heuristics of a Transport Services system. Protocol Selection: Protocol Selection represents the act of <del> choosing one or more sets of protocol options that are available to use based on the Transport Properties provided by the application, and the heuristics or policies within the Transport Services system. </del> <ins> choosing one or more sets of protocol stacks that are available to use based on the Transport Properties provided by the application, and the heuristics or policies within the Transport Services system. </ins> 4.2.2.

differ based on a selection from the available Paths.  Since different Paths will have distinct configurations for local addresses and DNS servers, attempts across different Paths will <del> perform separate DNS resolution stepss, which can lead to further </del> <ins> perform separate DNS resolution steps, which can lead to further </ins> racing of the resolved Remote Endpoints. Remote Endpoint Racing: Remote Endpoint Racing is the act of

races between two different Protocol Stacks, both MUST use the same security protocols and options. <del> Clients need to ensure that security APIs are used appropriately.  In cases where clients use an interface to provide sensitive keying material, e.g., access to private keys or copies of pre-shared keys (PSKs), key use needs to be validated.  For example, clients ought not to use PSK material created for the Encapsulating Security Protocol (ESP, part of IPsec) RFC4303 with QUIC, and clients ought not to use private keys intended for server authentication as a keys for client authentication. </del> <ins> Applications need to ensure that they use security APIs appropriately.  In cases where applications use an interface to provide sensitive keying material, e.g., access to private keys or copies of pre-shared keys (PSKs), key use needs to be validated.  For example, applications ought not to use PSK material created for the Encapsulating Security Protocol (ESP, part of IPsec) RFC4303 with QUIC, and applications ought not to use private keys intended for server authentication as a keys for client authentication. </ins> Moreover, Transport Services systems MUST NOT automatically fall back from secure protocols to insecure protocols, or to weaker versions of <del> secure protocols.  For example, if a client requests TLS, but the desired version of TLS is not available, its connection will fail. Clients are thus responsible for implementing security protocol fallback or version fallback by creating multiple Transport Services Connections, if so desired. </del> <ins> secure protocols.  For example, if an application requests TLS, but the desired version of TLS is not available, its connection will fail.  Applications are thus responsible for implementing security protocol fallback or version fallback by creating multiple Transport Services Connections, if so desired. </ins>