Change:
fixes Properties Terminology and aligns them to the API adds Properties as "Basic Object" updates Figure 2
NAME comments should be addressed now. Thanks for the reviews
Reviewing the arch doc right now which talkes about path and protocol selection properties, however, the API doc now has transport properties, connection properties, and message properties... I think we need to realign the terms here....
I admit to being slightly lost now with the naming and re-organization process... so maybe this is a left-over thing that should no longer exist... but: the API draft says "Collectively, Selection, Connection, and Message Properties can be referred to as Transport Properties." Unless I'm mistaken, this is what's needed: API draft: it seems strange how the list of selection properties (from 5.2.1 onward) appears out of nowhere. There should be a new heading, 5.3, just before what is now 5.2.1, called "Selection properties"Arch draft: with some exceptions that should perhaps be removed, the API draft doesn't really distinguish between "path" and "protocol" selection properties. Can we remove this distinction from the arch draft? Because of the availability of a protocol with certain abilities, a transport system might also make a decision about a certain path, and a path selection property might lead to a decision for a path that rules out a certain protocol... so this distinction seems to me to be a bit artificial anyway.
We converged on classifying properties into Selection, Connection, and Message Properties. If that is still true, then the architecture draft should refer to these classes of properties as well. I agree that there isn't necessarily a clear distinction between Path and Protocol Selection Properties, so we can merge them into a single class in the architecture document and just state that these properties can influence both path and protocol selection. About Transport Properties as a generic term to refer to all properties, I don't recall an extensive discussion on this, but I think it's alright (and makes more sense than what is in the API doc now, which basically uses Transport Properties as a synonym for Selection Properties).
I completely agree with NAME – don't re-iterate the whole discussion, please. We definitely need to make sure properties are consistent across all drafts. That primarily requires changes to Section 4.1.2. What I definitely would like to see is a short Section in the Architecture explaining what Properties are and that they are our tool to expose "knobs" of the transport. I am willing to volunteer for this, but It may take until next week.
closed by 5b173e2
Thanks for doing this - and thanks NAME for the close look you're taking

Discussion:
that an application can pass to describe its intent, requirements, prohibitions, and preferences for its networking operations.  For any system that provides generic Transport Services, these <del> properties SHOULD be defined to apply to multiple transport protocols.  Some properties are specific to a single transport protocol, and these are be exposed as non-generic interfaces (see Specific Protocol Properties preestablishment).  Properties can have a large impact on the rest of the aspects of the interface: they modify how establishment occurs, they influence the expectations around data transfer, and they determine the set of events that will be supported. </del> <ins> Selection Properties SHOULD be defined to apply to multiple transport protocols.  Selection Properties can have a large impact on the rest of the aspects of the interface: they modify how establishment occurs, they influence the expectations around data transfer, and they determine the set of events that will be supported. </ins> Establishment (establishment) focuses on the actions that an application takes on the basic objects to prepare for data

transmission is stopped, and state is torn down in the transport. The diagram below provides a high-level view of the actions taken <del> during the lifetime of a connection. </del> <ins> during the lifetime of a connection.  Note that some actions are alternatives (e.g., whether to initiate a connection or to listen for incoming connections), others are optional (e.g., setting Connection and Message Properties in Pre-Establishment), or have been omitted for brevity. </ins> 4.1.1.

potential connection.  It has state that describes parameters of a Connection that might exist in the future: the Local Endpoint from which that Connection will be established, the Remote Endpoint <del> (preestablishment) to which it will connect, and Path Selection Properties, Protocol Selection Properties, and Specific Protocol Properties that influence the choice of transport that a </del> <ins> (preestablishment) to which it will connect, and Selection Properties, that influence the choice of transport that a </ins> Connection will use.  A Preconnection can be fully specified and represent a single possible Connection, or it can be partially specified such that it represents a family of possible

Connection objects.  It is created from a Preconnection object that specifies the type of incoming connections it will accept. <ins> Transport Properties: Transport Properties allow the application to configure the Transport System and express their requirements, prohibitions, and preferences.  There are three kinds of Transport Properties: Selection Properties are used influence connection establishment. Connection Properties are used to configure the protocol instance and control per-connection behavior of the Transport System. Message Properties are used to configure per-message control per-connection behavior of the Transport System. Connection and Message Properties can also be specified prior establishment.  If done so, they are used as a default and MAY be used as an input to path selection and protocol selection.  Some Transport Properties only apply to a single protocol (transport protocol, IP, or security protocol).  The presence of such Transport Properties does not require that a specific protocol will be used when a Connection is established, but that if this protocol is employed, a particular set of options is to be used. </ins> 4.1.2. Endpoint: An Endpoint represents an identifier for one side of a

identifier for itself that it uses for transport connections.  For example, a local IP address and port. <del> Path Selection Properties: The Path Selection Properties consist of the options that an application can set to influence the selection of paths between the local and remote systems.  These options can take the form of requirements, prohibitions, or preferences.  Examples of options that influence path selection include the interface type (such as a Wi-Fi Ethernet connection, or a Cellular LTE connection), characteristics of the path that are locally known like the Maximum Transmission Unit (MTU) or discovered like the Path MTU (PMTU), or predicted based on cached information like expected throughput or latency. Protocol Selection Properties: The Protocol Selection Properties consist of the options that an application can set to influence the selection of transport protocol, or to configure the behavior of generic transport protocol features.  These options can take the form of requirements, prohibitions, and preferences.  Examples include reliability, service class, multipath support, and fast open support. Specific Protocol Properties: The Specific Protocol Properties refer to the subset of Protocol Properties options that apply to a single protocol (transport protocol, IP, or security protocol). The presence of such Properties does not require that a specific protocol will be used when a Connection is established, but that if this protocol is employed, a particular set of options is to be used. </del> <ins> Selection Properties: The Selection Properties consist of the options that an application can set to influence the selection of paths between the local and remote systems, to influence the selection of transport protocol, or to configure the behavior of generic transport protocol features.  These options can take the form of requirements, prohibitions, or preferences.  Examples of options that influence path selection include the interface type (such as a Wi-Fi Ethernet connection, or a Cellular LTE connection), characteristics of the path that are locally known like the Maximum Transmission Unit (MTU) or discovered like the Path MTU (PMTU), or predicted based on cached information like expected throughput or latency.  Examples of options that influence protocol selection and configuration of transport protocol features include reliability, service class, multipath support, and fast open support. </ins> 4.1.3.

multiple transport sub-flows). Candidate Path: One path that is available to an application and <del> conforms to the Path Selection Properties and System Policy. Candidate Paths are identified during the gathering phase (gathering) and can be used during the racing phase (racing). </del> <ins> conforms to the Selection Properties and System Policy.  Candidate Paths are identified during the gathering phase (gathering) and can be used during the racing phase (racing). </ins> Candidate Protocol Stack: One protocol stack that can be used by an application for a connection, of which there can be several.

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