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
- [Taps] Mirja Kühlewind's No Objection on draft-ie… Mirja Kühlewind
- Re: [Taps] Mirja Kühlewind's No Objection on draf… Gorry Fairhurst
- Re: [Taps] Mirja Kühlewind's No Objection on draf… Mirja Kuehlewind (IETF)