Re: [Taps] One RFC, or two, for draft-ietf-taps-transports-usage and draft-ietf-taps-transports-usage-udp

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Thu, 14 September 2017 16:02 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 CB5AD13301E; Thu, 14 Sep 2017 09:02:56 -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 tYpUsUiRHjgf; Thu, 14 Sep 2017 09:02:55 -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 D42601321C7; Thu, 14 Sep 2017 09:02:54 -0700 (PDT)
Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id EDA371B00168; Thu, 14 Sep 2017 17:02:30 +0100 (BST)
Message-ID: <59BAA815.5090209@erg.abdn.ac.uk>
Date: Thu, 14 Sep 2017 17:02:29 +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: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
CC: "taps@ietf.org" <taps@ietf.org>, taps-chairs@ietf.org
References: <CAKKJt-cpJ-SQ3J-O=OkqgQ-pu=xPfbYEdFCeTWD5zdzUb1_A8Q@mail.gmail.com> <CAKKJt-eM3kKuVo25jzU-RejuGZJ7ypZDQtJegGCcthpoRFU9Fw@mail.gmail.com>
In-Reply-To: <CAKKJt-eM3kKuVo25jzU-RejuGZJ7ypZDQtJegGCcthpoRFU9Fw@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/VZFJAgVfYnJ9hJRJkGkH3LYUby8>
Subject: Re: [Taps] One RFC, or two, for draft-ietf-taps-transports-usage and draft-ietf-taps-transports-usage-udp
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: Thu, 14 Sep 2017 16:02:57 -0000

On 14/09/2017, 15:55, Spencer Dawkins at IETF wrote:
> And, following up during the actual telechat ...
>
> On Wed, Sep 13, 2017 at 11:47 PM, Spencer Dawkins at IETF 
> <spencerdawkins.ietf@gmail.com <mailto:spencerdawkins.ietf@gmail.com>> 
> wrote:
>
>     Dear TAPS working group,
>
>     Multiple ADs have asked why these two drafts aren't a single
>     draft, in their ballots. Those are non-blocking comments, but I'd
>     like to explore that, before making a decision about what should
>     happen, and when.
>
>     It occurs to me that these ADs are reading both drafts pretty much
>     back-to-back in preparation for balloting during IESG Evaluation.
>
>     If people reading the two drafts back-to-back find the split to be
>     a distraction, I'd like to understand the views of the working
>     group as to how often you expect people to read both drafts, in
>     order to do TAPS.
>
>     I could imagine that people working on complete TAPS APIs might
>     need to read both drafts.
>
>     What about other folks you expect to read these documents? Do you
>     expect that some communities only need to read one of them?
>
>     Thanks in advance for any thoughts you can share.
>
>     Spencer, as responsible AD for TAPS
>
>
> Both documents were approved on the telechat today, pending comment 
> resolution of comments received during IESG Evaluation.
>
> So, my request to the working group to consider whether the suggestion 
> to combine these documents makes life easier for the readers you 
> expect will need to read one, the other, or both documents REALLY IS 
> an honest question, and not the IESG requiring fabulously late major 
> editorial changes without an active Discuss, because That Would Be Wrong.
>
> Either answer works. We'll Do The Right Thing.
>
> "Thanks in advance for your thoughts" :-)
>
> Spencer, as responsible AD, who the IESG said they trusted to "Do The 
> Right Thing"
>
>
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps

There was a proposal from IESG to consider whether we should merge the 
two usage documents. So after giving this some more thought, here is my 
2c about why I think we should keep the two documents:

First, I accept it may be easier for someone reviewing the history of 
TAPS and the rationale for design decisions to read just a single 
document - putting all the material in one place is always easier. 
However, if published in consecutive RFCs, I'm not convinced the 
material would be really hard for a reader to find.

I suggested there were two reasons behind separating this out when we 
did the work. First, the old and incomplete documentation for UDP needed 
a slightly different approach to finding the relevent RFCs. Second, the 
community of interest in using UDP at the IETF is typically to be found 
outside the TSV area, partly because of the wide variety of uses. A 
second document made this easier for these people to read. That's still 
the case for the material that was retained in the UDP usage document.

It would be my hope that the UDP document could form a long-needed part 
of the documentation for UDP. I expect this would continue to be a 
useful resource for anyone who wishes to build datagram support into a 
new stack, or just wants to program to this API, and avoids people 
needing to wade through 50-60 pages to find a section on a UDP API. I'd 
also hope (??!!) this document could be maintained in future as the API 
continues to develop.

Gorry