Re: [Taps] Mirja Kühlewind's No Objection on draft-ietf-taps-transports-usage-08: (with COMMENT)

Hi Gorry, 

see below.

> Am 12.09.2017 um 18:32 schrieb Gorry Fairhurst <gorry@erg.abdn.ac.uk>:
> 
> 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 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
> 