Draft: draft-ietf-taps-impl

Commentary: Implementation draft sec 3 : " In the remainder of this document , we only refer to Selection Properties because they are the more typical case and have to be handled by all implementations . The implementation stores these objects and properties as part of the Preconnection object for use during connection establishment . " I do n't understand these two sentences . In the API doc it seems we use the term Transport Properties for both selection and configuration properties . Why do we only talk about selection properties in this doc ? Also in the next sentence what 's meant by " objects and properties " ? I guess the object(s ) that hold the properties ? But then this is saying twice the same and we should only use one term to avoid confusion . 
 Also in the next section 3.1 : " Once an application specifies its Transport Parameters " I guess that should be Transport Properties instead ? Maybe it would also be good to say here " Once an application specifies its Transport Properties and Preference ( required , prefer , ignore , avoid , prohibit - see section 5.2 . of [ draft - taps - arch ] ) " . 
 I agree ; I suspect that this is ancient leftover text that should be cleaned up . 
 Some small changes suggested
Paragraph (version A):
During pre-establishment the application specifies the Endpoints to
be used for communication as well as its preferences via Selection
Properties and, if desired, also Connection Properties.  Generally,
Connection Properties should be configured as early as possible, as
they may serve as input to decisions that are made by the
implementation (the Capacity Profile may guide usage of a protocol
offering scavenger-type congestion control, for example).  In the
remainder of this document, we only refer to Selection Properties
because they are the more typical case and have to be handled by all
implementations.
Paragraph (version A):
The implementation stores these objects and properties as part of the
Preconnection object for use during connection establishment.  For
Selection Properties that are not provided by the application, the
implementation must use the default values specified in the Transport
Services API (I-D.ietf-taps-interface).
Paragraph (version B):
During pre-establishment the application specifies the Endpoints to
be used for communication as well as its preferences via Selection
Properties and, if desired, also Connection Properties.  Generally,
Connection Properties should be configured as early as possible,
because they can serve as input to decisions that are made by the
implementation (e.g., the Capacity Profile can guide usage of a
protocol offering scavenger-type congestion control).
Paragraph (version B):
The implementation stores these properties as a part of the
Preconnection object for use during connection establishment.  For
Selection Properties that are not provided by the application, the
implementation must use the default values specified in the Transport
Services API (I-D.ietf-taps-interface).
Paragraph (version A):
The transport system should have a list of supported protocols
available, which each have transport features reflecting the
capabilities of the protocol.  Once an application specifies its
Transport Parameters, the transport system should match the required
and prohibited properties against the transport features of the
available protocols.
Paragraph (version A):
The application requested Protocol Properties that include
requirements or prohibitions that cannot be satisfied by any of
the available protocols.  For example, if an application requires
"Configure Reliability per Message", but no such protocol is
available on the host running the transport system, e.g., because
SCTP is not supported by the operating system, this should result
in an error.
Paragraph (version A):
The application requested Protocol Properties that are in conflict
with each other, i.e., the required and prohibited properties
cannot be satisfied by the same protocol.  For example, if an
application prohibits "Reliable Data Transfer" but then requires
"Configure Reliability per Message", this mismatch should result
in an error.
Paragraph (version A):
It is important to fail as early as possible in such cases in order
to avoid allocating resources, e.g., to endpoint resolution, only to
find out later that there is no protocol that satisfies the
requirements.
Paragraph (version B):
The transport system should have a list of supported protocols
available, which each have transport features reflecting the
capabilities of the protocol.  Once an application specifies its
Transport Properties, the transport system matches the required and
prohibited properties against the transport features of the available
protocols.
Paragraph (version B):
A request by an application for Protocol Properties that include
requirements or prohibitions that cannot be satisfied by any of
the available protocols.  For example, if an application requires
"Configure Reliability per Message", but no such protocol is
available on the host running the transport system this should
result in an error, e.g., when SCTP is not supported by the
operating system.
Paragraph (version B):
A request by an application for Protocol Properties that are in
conflict with each other, i.e., the required and prohibited
properties cannot be satisfied by the same protocol.  For example,
if an application prohibits "Reliable Data Transfer" but then
requires "Configure Reliability per Message", this mismatch should
result in an error.
Paragraph (version B):
To avoid allocating resources, it is important that such cases fail
as early as possible, e.g., to endpoint resolution, only to find out
later that there is no protocol that satisfies the requirements.
Paragraph (version A):
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 Parameters actually work over the available paths, then the
transport system should notify the application with an InitiateError
event.  An InitiateError event should also be generated in case the
transport system finds no usable candidates to race.
Paragraph (version B):
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
transport system should notify the application with an InitiateError
event.  An InitiateError event should also be generated in case the
transport system finds no usable candidates to race.