Skip to main content

Telechat Review of draft-ietf-taps-transports-usage-udp-05

Request Review of draft-ietf-taps-transports-usage-udp
Requested revision No specific revision (document currently at 07)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2017-09-12
Requested 2017-08-31
Authors Gorry Fairhurst , Tom Jones
I-D last updated 2017-09-07
Completed reviews Genart Telechat review of -06 by Francis Dupont (diff)
Secdir Telechat review of -05 by Radia Perlman (diff)
Assignment Reviewer Radia Perlman
State Completed
Request Telechat review on draft-ietf-taps-transports-usage-udp by Security Area Directorate Assigned
Reviewed revision 05 (document currently at 07)
Result Has nits
Completed 2017-09-07
I have reviewed this document as part of the security directorate's

ongoing effort to review all IETF documents being processed by the IESG.

These comments were written primarily for the benefit of the security

area directors. Document editors and WG chairs should treat these

comments just like any other last call comments.

This informational document contains tutorial information on the use of the
sockets API to send and receive data over the UDP and UDP-lite protocols.
It is apparently part of an effort to write tutorial descriptions of APIs
to all IETF-standardized transport protocols.

This document refers the reader to the standards for all security
considerations. That is probably appropriate. It’s always difficult to
decide what information to include and what to exclude in a tutorial.  I
would have liked an explanation of how the sender knows whether to request
UDP or UDP-lite, since it doesn't look like UDP-lite would be compatible
with something that only speaks UDP.


The abstract refers to a current I-D intended to advance with this one as
RFCxxxx, which I believe is non-standard, but the RFC editor can probably
sort it out.

In the pdf version, one of the references to [I-D.ietf-taps-transports-usage]
is not preceded with a space and did not get turned into a clickable link.
There is a similar problem with [RFC8200] on page 4.

Page 4: “Operations should be provided that allows” -> “Operations should
be provided that allow”

Page 4: “[RFC6935] and [RFC6936] defines” -> “[RFC6935] and [RFC6936]