Subject: [secdir] Secdir review of draft-ietf-taps-transports-usage-udp-05

From: Radia Perlman <[email-masked]>
Date: Sun, 3 Sep 2017 21:33:11 -0700

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.

Nits:

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]
define”

Radia

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 11 Sep 2017 19:39:03 +0100

Thanks Radia,

I have started to collect together the comments I have received, and I 
am now preparing a revision that will address these.

Your comment seems to suggest merit in the introduction explaining a 
little about when an App should choose UDP v. UDP-Lite. I can see that 
would help a reader, and I suggest adding this to the intro:

"UDP is widely implemented and deployed. It is used for a wide range of 
applicatons. A special class of applications can derive benefit from 
having partially damaged payloads delivered, rather than discarded, when 
using paths that include error-prone links. Applications that can 
tolerate payload corruption can choose to use UDP-Lite instead of UDP. 
Conversely, UDP applications could choose to use UDP-Lite, but this is 
currently less widely deployed and users could encounter paths that do 
not support UDP-LIte. These topics are discussed more in section 3.4 of 
the UDP Usage Guidelines [RFC8085]."

I have now addressed the editorial/format corrections requested in the 
version I edit - thanks again.

Best wishes,

Gorry

---

On 04/09/2017, 05:33, Radia Perlman wrote:
> 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.
>
> 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.
>
> Nits:
>
> 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”
>