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
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
