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

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 11 Sep 2017 08:48:55 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-taps-transports-usage-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Fully editorial comments:

- First paragraph in intro: s/underlying TAPS system/underlying Transport
Services (TAPS) system/

- This should not use normative language: "TCP implementations MUST NOT use TFO
by default..." (see comment from EKR)

- Also there is half a sentence missing in the same paragraph: "more than TCP's
maximum segment size (minus options used in the SYN)."

- s/Differentiated Services (diffuser)/Differentiated Services (diffserv)/ or
s/Differentiated Services (diffuser)/Differentiated Services (DiffServ)/

- 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.

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 12 Sep 2017 17:32:35 +0100

On 11/09/2017, 16:48, Mirja Kühlewind wrote:
> <snip>
> <snip>
> _______________________________________________
> Taps mailing list
> [email-masked]
> 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 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.

Gorry

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 12 Sep 2017 23:16:09 +0200

Hi Gorry, 

see below.

> Am 12.09.2017 um 18:32 schrieb Gorry Fairhurst <[email-masked]>:
> 
> 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