Hi Gorry,

> On Sep 14, 2017, at 6:19 AM, Gorry Fairhurst <go...@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

_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Reply via email to