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

From: Suresh Krishnan <[email-masked]>
Date: Wed, 13 Sep 2017 16:12:58 -0700

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.

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 14 Sep 2017 11:19:55 +0100

Thanks Suresh, please see below.

On 14/09/2017, 00:12, Suresh Krishnan wrote:
> _______________________________________________
> Taps mailing list
> [email-masked]
> 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

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 14 Sep 2017 18:37:04 -0400

Hi Gorry,

> On Sep 14, 2017, at 6:19 AM, Gorry Fairhurst <[email-masked]> wrote:
> 
> 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:
> 
> "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:"
> 
> (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