Draft: draft-ietf-taps-arch

Commentary: Having read -05 , I have some more comments , mostly editorial . Opening an issue in case there 's anything to discuss . Otherwise I might just do a PR against -arch if that 's fine with the authors . In Section 4.1.1 : " Event Handling ( Section 4.1.5 ) defines the set of properties about which an application can receive notifications during the lifetime of transport objects . " Set of properties ? Section 4.1.5 do not refer to specific properties ( as in : Transport Properties ) , but just lists what kinds of events exist . So I suggest changing text in Section 4.1.1 to say something like : " Event Handling ( Section 4.1.5 ) defines categories of notifications which an application can receive during the lifetime of transport objects . " In Section 4.1.4 : " When receiving Messages , Message Properties can contain per - protocol properties for properties that are sent between the endpoints . " Why is this constrained to properties that are sent between endpoints ? Could n't an implementation also set Message Properties that were not signaled ? Also , what does " per - protocol " mean here ? Also , too many " properties " in this sentence . I suggest changing this to something like : " When receiving Messages , Message Properties can contain information about the received message , such as signalled by the other endpoint . " Still Section 4.1.4 : " The status of the Send operation can be delivered back to the sending application in an event " Can be ? I thought this always happens ? The API draft in Section 7.3 says that for each Send ( ) , the application gets exactly one event ? So I think here this should be phrased as " is delivered " or even MUST . Section 4.1.5 : " This section provides the top - level categories of events events that can be delivered to an application . " Top - level categories ? Are there more levels of categories ? Maybe just say " categories " ? Also , duplicate word : " events events " . Section 4.2.1 : " Protocol Selection : [ … ] choosing one or more sets of protocol options " I do n't think protocol options is the right word . Is n't this about racing protocol stacks ? Below we use " protocol options " to mean something else , so here we should just say " choosing between multiple protocol stacks " . " separate DNS resolution stepss " ( typo ) Section 6 : " Clients need to ensure that security APIs are used appropriately . " Who or what is a client ? An application ? Or the transport system itself ? I think it 's an application . " Clients " is not used elsewhere in the text . So this section should replace " clients " with " applications " . 
 All suggestions here are good , please send a PR . I 'd rephrase the following : " When receiving Messages , Message Properties can contain information about the received message , such as signalled by the other endpoint . " to " When receiving Messages , Message Properties can contain information about the received message , such as  generated at the receiver and information signalled by the remote endpoint " ( " such as " needs a noun , and I 'd like to be more explicit here )
Paragraph (version A):
Event Handling (events) defines the set of properties about which
an application can receive notifications during the lifetime of
transport objects.  Events MAY also provide opportunities for the
application to interact with the underlying transport by querying
state or updating maintenance options.
Paragraph (version B):
Event Handling (events) defines categories of notifications which
an application can receive during the lifetime of transport
objects.  Events MAY also provide opportunities for the
application to interact with the underlying transport by querying
state or updating maintenance options.
Paragraph (version A):
Message Properties: Message Properties can be used to annotate
specific Messages.  These properties might only apply to how
Message is sent (such as how the transport will treat
prioritization and reliability), but can also include properties
that specific protocols encode and communicate to the Remote
Endpoint.  Message Properties MAY be set on a Preconnection to
define default properties for sending.  When receiving Messages,
Message Properties can contain per-protocol properties for
properties that are sent between the endpoints.
Paragraph (version A):
Send: The action to transmit a Message or partial Message over a
Connection to the remote system.  The interface to Send MAY
include Message Properties specific to how the Message content is
to be sent.  The status of the Send operation can be delivered
back to the sending application in an event (events).
Paragraph (version B):
Message Properties: Message Properties can be used to annotate
specific Messages.  These properties might only apply to how
Message is sent (such as how the transport will treat
prioritization and reliability), but can also include properties
that specific protocols encode and communicate to the Remote
Endpoint.  Message Properties MAY be set on a Preconnection to
define default properties for sending.  When receiving Messages,
Message Properties can contain information about the received
Message, such as metadata generated at the receiver and
information signalled by the remote endpoint.
Paragraph (version B):
Send: The action to transmit a Message or partial Message over a
Connection to the remote system.  The interface to Send MAY
include Message Properties specific to how the Message content is
to be sent.  The status of the Send operation MUST be delivered
back to the sending application in an event (events).
Paragraph (version A):
This section provides the top-level categories of events that can be
delivered to an application.  This list is not exhaustive.
Paragraph (version B):
This section provides the categories of events that can be delivered
to an application.  This list is not exhaustive.
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 Transport Properties provided by the
application, and the heuristics or policies within the Transport
Services system.
Paragraph (version B):
Protocol Selection: Protocol Selection represents the act of
choosing one or more sets of protocol stacks that are available to
use based on the Transport Properties provided by the application,
and the heuristics or policies within the Transport Services
system.
Paragraph (version A):
Path Racing: Path Racing is the act of attempting to establish, or
scheduling attempts to establish, multiple Protocol Stacks that
differ based on a selection from the available Paths.  Since
different Paths will have distinct configurations for local
addresses and DNS servers, attempts across different Paths will
perform separate DNS resolution stepss, which can lead to further
racing of the resolved Remote Endpoints.
Paragraph (version B):
Path Racing: Path Racing is the act of attempting to establish, or
scheduling attempts to establish, multiple Protocol Stacks that
differ based on a selection from the available Paths.  Since
different Paths will have distinct configurations for local
addresses and DNS servers, attempts across different Paths will
perform separate DNS resolution steps, which can lead to further
racing of the resolved Remote Endpoints.
Paragraph (version A):
Clients need to ensure that security APIs are used appropriately.  In
cases where clients use an interface to provide sensitive keying
material, e.g., access to private keys or copies of pre-shared keys
(PSKs), key use needs to be validated.  For example, clients ought
not to use PSK material created for the Encapsulating Security
Protocol (ESP, part of IPsec) RFC4303 with QUIC, and clients ought
not to use private keys intended for server authentication as a keys
for client authentication.
Paragraph (version A):
Moreover, Transport Services systems MUST NOT automatically fall back
from secure protocols to insecure protocols, or to weaker versions of
secure protocols.  For example, if a client requests TLS, but the
desired version of TLS is not available, its connection will fail.
Paragraph (version B):
Applications need to ensure that they use security APIs
appropriately.  In cases where applications use an interface to
provide sensitive keying material, e.g., access to private keys or
copies of pre-shared keys (PSKs), key use needs to be validated.  For
example, applications ought not to use PSK material created for the
Encapsulating Security Protocol (ESP, part of IPsec) RFC4303 with
QUIC, and applications ought not to use private keys intended for
server authentication as a keys for client authentication.