Draft: draft-ietf-taps-interface

Commentary: The guidance applies to any connectionless transport . 
 " Connection establishment is only a local operation for a Datagram transport ( e.g. , UDP(-Lite ) ) " : I think the criterion is not Datagram transports but " transports without a handshake " or " connectionless protocols " as it is used later in the document . 
 I wrote , and I suggest we use " connectionless protocols " explicitly mentioning examples of UDP and UDP - Lite when used as a transport without a handshake . 
 To whoever plans to address this : I checked occurrences of the word " datagram " in the architecture and API drafts , and I found ( only ) one sentence that needs fixing on similar grounds , I think , in the API draft : in Section 8.1.4 " Timeout for keep alive packets " . Surely the guidance regarding this matter in the UDP usage RFC is related to the fact that UDP(-Lite ) is connectionless , not that it 's datagram based . 
 Starting to fix this . 
 LGTM
Paragraph (version A):
To aid readability, implementations MAY provide additional
convenience functions to simplify use of Selection Properties: see
preference-conv for examples.  In addition, implementations MAY
provide a mechanism to create TransportProperties objects that are
preconfigured for common use cases as outlined in property-profiles.
Paragraph (version B):
To aid readability, implementations MAY provide additional
convenience functions to simplify use of Selection Properties: see
preference-conv for examples.  In addition, implementations MAY
provide a mechanism to create TransportProperties objects that are
preconfigured for common use cases, as outlined in property-profiles.
Paragraph (version A):
A Transport Services API can request a protocol that supports sending
keep alive packets keep-alive.  If this property is Numeric, it
specifies the maximum length of time an idle connection (one for
which no transport packets have been sent) should wait before the
Local Endpoint sends a keep-alive packet to the Remote Endpoint.
Adjusting this Property will only take effect when the underlying
stack supports sending keep-alive packets.  Guidance on setting this
value for datagram transports is provided in RFC8085.  A value
greater than the connection timeout (conn-timeout) or the enumerated
value "Disabled" will disable the sending of keep-alive packets.
Paragraph (version B):
A Transport Services API can request a protocol that supports sending
keep alive packets keep-alive.  If this property is Numeric, it
specifies the maximum length of time an idle connection (one for
which no transport packets have been sent) should wait before the
Local Endpoint sends a keep-alive packet to the Remote Endpoint.
Adjusting this Property will only take effect when the underlying
stack supports sending keep-alive packets.  Guidance on setting this
value for connection-less transports is provided in RFC8085.  A value
greater than the connection timeout (conn-timeout) or the enumerated
value "Disabled" will disable the sending of keep-alive packets.
Paragraph (version A):
Of course any communication over a network reveals usage
characteristics, as all packets, as well as their timing and size,
are part of the network-visible wire image RFC8546.  However, the
selection of a protocol and its configuration also impacts which
information is visible, potentially in clear text, and which other
entities can access it.  In most cases, information provided for
protocol and path selection should not directly translate to
information that can be observed by network devices on the path.
However, there might be specific configuration information that is
intended for path exposure, e.g., a DiffServ codepoint setting, that
is either provided directly by the application or indirectly
configured for a traffic profile.
Paragraph (version B):
Of course any communication over a network reveals usage
characteristics, because all packets, as well as their timing and
size, are part of the network-visible wire image RFC8546.  However,
the selection of a protocol and its configuration also impacts which
information is visible, potentially in clear text, and which other
entities can access it.  In most cases, information provided for
protocol and path selection should not directly translate to
information that can be observed by network devices on the path.
However, there might be specific configuration information that is
intended for path exposure, e.g., a DiffServ codepoint setting, that
is either provided directly by the application or indirectly
configured for a traffic profile.