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

[Spencer Dawkins at IETF <[e-mail]>]

Dear TAPSters,

On Thu, Sep 14, 2017 at 11:02 AM, Gorry Fairhurst <[e-mail]>
wrote:

> 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 <
>> [e-mail] <mailto:[e-mail]>>
>> 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
>> [e-mail]
>> 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
>

Gorry's e-mail captured pretty much everything I need to know. I have one
more question, because I know that people have implemented TAPSish APIs and
demonstrated them.

If you worked on one of those APIs, did you have to read both documents?

Thanks in advance, and asking for (14) friends ...

Spencer, as responsible AD