Draft: draft-ietf-taps-arch

Commentary: fixes Properties Terminology and aligns them to the API adds Properties as " Basic Object " updates Figure 2 
 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 does n'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 is n'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 do n'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 – do n'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  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 
 Thanks for doing this - and thanks for the close look you 're taking
Paragraph (version A):
Pre-Establishment (preestablishment) encompasses the properties
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
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.
Paragraph (version B):
Pre-Establishment (preestablishment) encompasses the properties
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
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.
Paragraph (version A):
The diagram below provides a high-level view of the actions taken
during the lifetime of a connection.
Paragraph (version B):
The diagram below provides a high-level view of the actions taken
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.
Paragraph (version B):
Selection Properties are used influence connection
establishment.
Paragraph (version B):
Connection Properties are used to configure the protocol
instance and control per-connection behavior of the Transport
System.
Paragraph (version B):
Message Properties are used to configure per-message control
per-connection behavior of the Transport System.
Paragraph (version B):
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.
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version A):
Candidate Path: One path that is available to an application and
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).
Paragraph (version B):
Candidate Path: One path that is available to an application and
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).
Paragraph (version A):
Path Selection: Path Selection represents the act of choosing one
or more paths that are available to use based on the Path
Selection Properties provided by the application, the policies and
heuristics of a Transport Services system.
Paragraph (version A):
Protocol Selection: Protocol Selection represents the act of
choosing one or more sets of protocol options that are available
to use based on the Protocol Properties provided by the
application, and a Transport Services system's policies and
heuristics.
Paragraph (version B):
Path Selection: Path Selection represents the act of choosing one
or more paths that are available to use based on the Selection
Properties provided by the application, the policies and
heuristics of a Transport Services system.
Paragraph (version B):
Protocol Selection: Protocol Selection represents the act of
choosing one or more sets of protocol options that are available
to use based on the Transport Properties provided by the
application, and a Transport Services system's policies and
heuristics.