Original text:
local interfaces that are connected to different access networks. Internally, the transport system will first exclude all protocols and <del> paths that match a Prohibit, then only keep candidates that match a Require, then sort candidates according to Preferred properties, and then use Avoided properties as a tiebreaker.  In case of conflicts between Protocol and Path Selection Properties, Path Selection Properties take precedence.  For example, if an application indicates a preference for a specific path, but also a preference for a protocol not available on this path, the transport system will try the path first, so the Protocol Selection Property might not have an effect. </del>  All Transport Properties used in the pre-establishment phase are collected in a TransportProperties Object that is passed to the The Preconnection Object must be specified with both a Local Endpoint and a Remote Endpoint, and also the transport properties and security <del> parameters needed for Protocol Stack selection.  The Rendezvous() Action causes the Preconnection to listen on the Local Endpoint for an incoming Connection from the Remote Endpoint, while simultaneously trying to establish a Connection from the Local Endpoint to the Remote Endpoint.  This corresponds to a TCP simultaneous open, for example. </del>  The Rendezvous() Action consumes the Preconnection.  Once Rendezvous() has been called, no further properties may be added to represent the concrete addresses, local and server reflexive, on which a Rendezvous() for the Preconnection will listen for incoming Connections.  This list can be passed to a peer via a signalling <del> protocol, such as SIP or WebRTC, to configure the remote. </del>  6.4. i.e., when the data derived from the Message has been passed down or through the underlying Protocol Stack and is no longer the responsibility of the implementation of this interface.  The exact <del> disposition of the Message when the Sent Event occurs is specific to the implementation and the constraints on the Protocol Stacks implied by the Connection's Transport Properties.  The Sent Event contains an implementation-specific reference to the Message to which it applies. </del>  Sent Events allow an application to obtain an understanding of the amount of buffering it creates.  That is, if an application calls the

Reviewer comments:
quickly adding this to fix NAME nits before -01 submission
Text: Internally, the transport system will first exclude all protocols and paths that match a Prohibit, then only keep candidates that match a Require, then sort candidates according to Preferred properties, and then use Avoided properties as a tiebreaker. does not read correct for me... I understand excluding prohibit, but the action on require seems wrong. I expected to remove candidates with prohibit and remove candidates that do NOT have require. What is written is different. —- I would prefer a para break before: The Rendezvous() Action causes the to show the change of topic. — Refs needed: SIP or WebRTC — maximum Message size should this be capitalised? What is maxlen? The same value? Of different? —- I could not finally understand what is intended by this text; The exact disposition of the Message when the Sent Event occurs is specific to the implementation and the constraints on the Protocol Stacks implied by the Connection's Transport Properties.

Revised text:
local interfaces that are connected to different access networks. Internally, the transport system will first exclude all protocols and  <ins> paths that match a Prohibit, then exclude all protocols and paths that do not match a Require, then sort candidates according to Preferred properties, and then use Avoided properties as a tiebreaker.  In case of conflicts between Protocol and Path Selection Properties, Path Selection Properties take precedence.  For example, if an application indicates a preference for a specific path, but also a preference for a protocol not available on this path, the transport system will try the path first, so the Protocol Selection Property might not have an effect. </ins> All Transport Properties used in the pre-establishment phase are collected in a TransportProperties Object that is passed to the The Preconnection Object must be specified with both a Local Endpoint and a Remote Endpoint, and also the transport properties and security  <ins> parameters needed for Protocol Stack selection. The Rendezvous() Action causes the Preconnection to listen on the Local Endpoint for an incoming Connection from the Remote Endpoint, while simultaneously trying to establish a Connection from the Local Endpoint to the Remote Endpoint.  This corresponds to a TCP simultaneous open, for example. </ins> The Rendezvous() Action consumes the Preconnection.  Once Rendezvous() has been called, no further properties may be added to represent the concrete addresses, local and server reflexive, on which a Rendezvous() for the Preconnection will listen for incoming Connections.  This list can be passed to a peer via a signalling  <ins> protocol, such as SIP RFC3261 or WebRTC RFC7478, to configure the remote. </ins> 6.4. i.e., when the data derived from the Message has been passed down or through the underlying Protocol Stack and is no longer the responsibility of the implementation of this interface.  The exact  <ins> disposition of the Message (i.e., whether it has actually been transmitted, moved into a buffer on the network interface, moved into a kernel buffer, and so on) when the Sent Event occurs is implementation-specific.  The Sent Event contains an implementation- specific reference to the Message to which it applies. </ins> Sent Events allow an application to obtain an understanding of the amount of buffering it creates.  That is, if an application calls the