Re: [Taps] Suresh Krishnan's No Objection on draft-ietf-taps-transports-usage-udp-06: (with COMMENT)

Thanks Suresh, please see below.

On 14/09/2017, 00:12, Suresh Krishnan wrote:
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-taps-transports-usage-udp-06: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage-udp/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> * Section 1
>
> "The UDP and UDP-Lite sockets API differs from that for TCP in several key
> ways."
>
> I was expecting the document to at least briefly describe the differences
> following this. The socket option text that follows does not really fit the
> bill. e.g. SO_REUSEADDR applies to TCP as well as UDP.
>
>
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps
I see, that wasn't quite the way I expected it to be read, so maybe we 
can suggest a slight re-write to the introduction to avoid misleading 
people and thereby better introduce what follows in the document:

After the reference to Stevens, we suggest to insert:

"In UDP and UDP-Lite, each datagram is a self-contained message of a 
specified length, and options at the transport layer can be used to set 
properties for all subsequent datagrams sent using a socket or changed 
for each datagram. For datagrams, this can require the application to 
use the API to set IP-level information (the IP Time To Live (TTL), 
Differentiated Services (DiffServ) Code Point, IP fragmentation, etc) 
for the datagrams it sends and receives. In contrast, when using TCP and 
other connection-oriented transports, the IP-level information normally 
either remains the same for the duration of a connection or is 
controlled by the transport protocol rather than the application.

Socket options are used in the socket API to provide additional 
functions Examples of socket options (in this case commonly used by UDP 
multicast applications) include:"

... followed by the three example sockopts.

(If we add this I think it also helps explain why the network-layer 
primitives appear. We would of course avoide redefining TTL, etc in the 
following paras.)

Tom & Gorry