Draft: draft-ietf-taps-interface

Commentary: , , , , , . 
 In 8.1.1 the second sentence is convoluted . Is there a way to restate it without as many nots , nons , an different zeros ? 
 Do you really mean " host " at " ( endpoints ) SHOULD represent the same host " in section 6 , or do you mean something more like service , given that an endpoint may configured with a DNS name ? 
 actually we mean service , good catch . 
 The " reformatted where necessary " part of the requirement in the last paragraph of 4.1 makes the MUST NOT almost impossible to conform to . I think I understand what the paragraph is trying to say , but the current formulation leaves the reader guessing . I think you are trying to say " Avoid using any of the terms listed as keywords in the protocol numbers registry as any part of a vendor or implementation - specific property name " . 
 The first sentence - paragraph of section 4 is complex . Please break it apart . 
 3 has a comment that 's too long for the text version 
 In the text version of the document , the last paragraph before 3.1.3 has some  ( ~~~ ) that has leaked through . 
 As you can tell , I do n't think the documents do what the first sentence of the API summary claims . This document would not lose anything if you deleted the sentence . 
 Agreed , we can lose this sentence . 
 Why ? Removing this makes no sense to me . 
 For one , it 's redundant - it only repeats what we already say earlier twice . 
 Ah , I see - so just this one instance ..... then go ahead , we do n't need to say something twice .
Paragraph (version A):
The Transport Services API is the basic common abstract application
programming interface to the Transport Services Architecture defined
in the TAPS Architecture I-D.ietf-taps-arch.
Paragraph (version A):
Each application using the Transport Services Interface declares its
preferences for how the transport service should operate using
properties at each stage of the lifetime of a connection using
Transport Properties, as defined in I-D.ietf-taps-arch.
Paragraph (version B):
Each application using the Transport Services Interface declares its
preferences for how the transport service should operate.  This is
done by using Transport Properties, as defined in I-D.ietf-taps-arch,
at each stage of the lifetime of a connection.
Paragraph (version A):
Namespaces for each of the keywords provided in the IANA protocol
numbers registry (see https://www.iana.org/assignments/protocol-
numbers/protocol-numbers.xhtml), reformatted where necessary to
conform to an implementation's naming conventions, are reserved for
Protocol Specific Properties and MUST NOT be used for vendor or
implementation-specific properties.
Paragraph (version B):
Namespaces for each of the keywords provided in the IANA protocol
numbers registry (see https://www.iana.org/assignments/protocol-
numbers/protocol-numbers.xhtml) are reserved for Protocol Specific
Properties and MUST NOT be used for vendor or implementation-specific
properties.  Avoid using any of the terms listed as keywords in the
protocol numbers registry as any part of a vendor- or implementation-
specific property name.
Paragraph (version A):
If more than one Remote Endpoint is specified on the Preconnection,
then all the Remote Endpoints on the Preconnection SHOULD represent
the same host.  For example, the Remote Endpoints might represent
various network interfaces of a host, or a server reflexive address
that can be used to reach a host, or a set of hosts that provide
equivalent local balanced service.
Paragraph (version B):
If more than one Remote Endpoint is specified on the Preconnection,
then all the Remote Endpoints on the Preconnection SHOULD represent
the same service.  For example, the Remote Endpoints might represent
various network interfaces of a host, or a server reflexive address
that can be used to reach a host, or a set of hosts that provide
equivalent local balanced service.
Paragraph (version A):
This property specifies the minimum number of bytes in a received
message that need to be covered by a checksum.  A special value of 0
means that a received packet does not need to have a non-zero
checksum field.  A receiving endpoint will not forward messages that
have less coverage to the application.  The application is
responsible for handling any corruption within the non-protected part
of the message RFC8085.
Paragraph (version B):
This property specifies the minimum number of bytes in a received
message that need to be covered by a checksum.  A receiving endpoint
will not forward messages that have less coverage to the application.
The application is responsible for handling any corruption within the
non-protected part of the message RFC8085.  A special value of 0
means that a received packet may also have a zero checksum field.