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
<[email protected] <mailto:[email protected]>>
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
[email protected]
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
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
