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

Hi Gorry,

> On Sep 14, 2017, at 6:19 AM, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
> 
> 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.)

Excellent. This new text would completely address my concern. Thanks for proposing that.

Regards
Suresh