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

Gorry Fairhurst <> Mon, 11 September 2017 18:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7EFB71331B0; Mon, 11 Sep 2017 11:39:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iNDvcvxFC9Uu; Mon, 11 Sep 2017 11:39:30 -0700 (PDT)
Received: from ( [IPv6:2001:630:241:204::f0f0]) by (Postfix) with ESMTP id 8F156132EBE; Mon, 11 Sep 2017 11:39:30 -0700 (PDT)
Received: from Gs-MacBook-Pro.local ( []) by (Postfix) with ESMTPA id A30501B000E1; Mon, 11 Sep 2017 19:39:04 +0100 (BST)
Message-ID: <>
Date: Mon, 11 Sep 2017 19:39:03 +0100
From: Gorry Fairhurst <>
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Radia Perlman <>
CC: "" <>, The IESG <>,
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [secdir] Secdir review of draft-ietf-taps-transports-usage-udp-05
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Sep 2017 18:39:36 -0000

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,



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