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

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Mon, 11 September 2017 18:39 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFB71331B0; Mon, 11 Sep 2017 11:39:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNDvcvxFC9Uu; Mon, 11 Sep 2017 11:39:30 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 8F156132EBE; Mon, 11 Sep 2017 11:39:30 -0700 (PDT)
Received: from Gs-MacBook-Pro.local (at-zeroshell-1.erg.abdn.ac.uk [139.133.217.68]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id A30501B000E1; Mon, 11 Sep 2017 19:39:04 +0100 (BST)
Message-ID: <59B6D847.5040709@erg.abdn.ac.uk>
Date: Mon, 11 Sep 2017 19:39:03 +0100
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Reply-To: gorry@erg.abdn.ac.uk
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 <radiaperlman@gmail.com>
CC: "secdir@ietf.org" <secdir@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-taps-transports-usage-udp.all@tools.ietf.org
References: <CAFOuuo5HjRn7SfT=q2muJ3LFner3AjpOnHTSnEObrqUpgVDWyg@mail.gmail.com>
In-Reply-To: <CAFOuuo5HjRn7SfT=q2muJ3LFner3AjpOnHTSnEObrqUpgVDWyg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/4Ea8uoOZZoRVo3-9oapI6lg26yU>
Subject: Re: [secdir] Secdir review of draft-ietf-taps-transports-usage-udp-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=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,

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
>