Hi Gorry, see below.
> Am 12.09.2017 um 18:32 schrieb Gorry Fairhurst <[email protected]>: > > 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 >> [email protected] >> 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 just made the experience that I started reviewing draft-ietf-taps-transport-usage, then had to stop in the middle, read draft-ietf-taps-udp-usage and then return to the first one. The main problem is that draft-ietf-taps-transport-usage is so closely coupled to the other draft that is does not make sense stand-alone. > > 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. I’am actually not sure if there is any additional value in having this draft as a stand-alone draft, compared to just advise people to only read those sections they are interested in of a combined draft. The problem is, while the udp draft may make sense as a stand-alone draft, that’s not the case for this draft (draft-ietf-taps-transport-usage). I didn’t had a strong opinion about this before but now that I've read both draft as a whole together, I found it really uncomfortable to have this split up in two. However, this is only a comment and the authors/wg needs to decide. Mirja > > Gorry > _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
