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

[Gorry Fairhurst <[e-mail]>]

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:
>
> 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
>