Re: [Taps] Mirja Kühlewind's No Objection on draft-ietf-taps-transports-usage-08: (with COMMENT)

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Tue, 12 September 2017 16:33 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3569133076; Tue, 12 Sep 2017 09:33:06 -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 uGb-eTjgRyhn; Tue, 12 Sep 2017 09:33:04 -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 4ABF213308D; Tue, 12 Sep 2017 09:33:04 -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 90BE31B00040; Tue, 12 Sep 2017 17:32:35 +0100 (BST)
Message-ID: <59B80C23.80803@erg.abdn.ac.uk>
Date: Tue, 12 Sep 2017 17:32:35 +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: Mirja Kühlewind <ietf@kuehlewind.net>
CC: The IESG <iesg@ietf.org>, draft-ietf-taps-transports-usage@ietf.org, taps-chairs@ietf.org, Zaheduzzaman.Sarker@ericsson.com, taps@ietf.org
References: <150514493541.9712.4517222531106973475.idtracker@ietfa.amsl.com>
In-Reply-To: <150514493541.9712.4517222531106973475.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/ZzoPrxCm2vROH3ofVbFExS3VuPE>
Subject: Re: [Taps] Mirja Kühlewind's No Objection on draft-ietf-taps-transports-usage-08: (with COMMENT)
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussions on Transport Services <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Sep 2017 16:33:07 -0000

On 11/09/2017, 16:48, Mirja Kühlewind wrote:
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-taps-transports-usage-08: No Objection
>
> <snip>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> <snip>
>
> - I (still) don't understand why draft-ietf-taps-transports-usage-udp was kept
> in a separate document, given there is even a separate empty section in this
> doc. You basically have to stop reading there, go to the other doc, read it,
> and come back. That doesn't make sense to me.
>
>
> _______________________________________________
> Taps mailing list
> TapIs@ietf.org
> https://www.ietf.org/mailman/listinfo/taps
I'll speak only to the last comment which was discussed in IETF-96.

The WG looked at this and there were pro's and con's in both a single 
document, and two separate documents. In the end, the decision by the WG 
was to publish the initial datagram analysis (UDP and UDP-L) as a 
separate document, which cut them into smaller pieces and was more 
managebale, but the WG would request the RFC-Ed to publish the two 
documents as a pair.

I see another advantage: Much of the API requirements for UDP is 
scattered across various RFCs - and some implicit (RFCs that state a 
need to allow the stack to do something, but do not indicate how it will 
be done). It was thought a separate datagram document may have further 
utility for people as a informative single reference on how to present a 
datagram API, beyond its input to the TAPs transport design.

Gorry