Subject: Re: [Taps] WGLC start for -transports-usage- docs

From: Tommy Pauly <[email-masked]>
Date: Sun, 04 Jun 2017 13:40:26 -0700

Agreed, these both look ready to go! Just a few minor typographical nits below; these could be cleaned up later.

Best,
Tommy

Usage Draft:

- In Section 3.1, the style of most items is lower case without underscores; however there are "USER TIMEOUT event:” and "ERROR_REPORT event:”, and then the rest of the list is in camel-case like "Type-of-Service:”. These should probably be cleaned up. Same for other lists.

- In Section 5.1, would it be useful to explicitly mention MPTCP for the common elements with TCP, or simply mention that anything that applies to TCP also applies to MPTCP?

UDP Usage Draft:

 - Section 3 has some mismatched parenthetical clauses:
(in and how the
   transport is used (based on abstract API descriptions, where they are
   available).
- Section 3.1 has a sentence that doesn’t parse well:

should be able to create receive, source and
   destination ports and addresses

- Also in Section 3.1, it seems that there should be a comma before the “or by” rather than a full stop.

 1.  bind(): A bind operation sets the local port, either
          implicitly, triggered by a "sendto" operation on an unbound,
          unconnected socket using an ephemeral port.  Or by an explicit
          "bind" to use a configured or well-known port.

- Section 3.1, "ERROR_REPORT The ERROR_REPORT” is missing the colon that all other items have. Same for SET_MIN_COVERAGE in section 3.2

> On May 30, 2017, at 3:14 AM, Brian Trammell (IETF) <[email-masked]> wrote:
> 
> hi Aaron, all,
> 
> I've read these, and IMO they're ready for publication. Many thanks to the authors for the impressive amount of work that went into them!
> 
> Cheers,
> 
> Brian
> 
> 
>> On 29 May 2017, at 18:30, Aaron Falk <[email-masked]> wrote:
>> 
>> Dear TAPS working group:
>> 
>> The authors have indicated the two drafts below are complete and are ready for a final working group review. WGLC starts today and will be three weeks, concluding June 19. Send comments, including an indication that the docs are ready for publication, to the working group list.
>> 
>> 	• On the Usage of Transport Features Provided by IETF Transport Protocols
>> 	• Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP- Lite) Transport Protocols
>> —aaron
>> 
>> _______________________________________________
>> Taps mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/taps
> 
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: "Aaron Falk" <[email-masked]>
Date: Thu, 15 Jun 2017 11:42:41 -0400

Reminder: WGLC on these docs concludes this coming Monday.  Please read 
and comment.

Thanks,

—aaron

On 29 May 2017, at 12:30, Aaron Falk wrote:

> Dear TAPS working group:
>
> The authors have indicated the two drafts below are complete and are 
> ready for a final working group review.  WGLC starts today and will be 
> three weeks, concluding June 19.  Send comments, including an 
> indication that the docs are ready for publication, to the working 
> group list.
>
> * [On the Usage of Transport Features Provided by IETF Transport 
> Protocols](https://www.ietf.org/internet-drafts/draft-ietf-taps-transports-usage-05.txt)
> * [Features of the User Datagram Protocol (UDP) and Lightweight UDP 
> (UDP- Lite) Transport 
> Protocols](https://www.ietf.org/internet-drafts/draft-ietf-taps-transports-usage-udp-03.txt)
>
>
> —aaron

---

From: "Aaron Falk" <[email-masked]>
Date: Mon, 19 Jun 2017 14:20:53 -0400

IMO, the doc looks good and should be published.  See below for a couple 
of comments that should be addressed before submission for AD review.

For both docs, the introduction (plus the appendix) does a good job of 
talking about ‘what’ is in the doc but the 
draft-ietf-taps-transports-usage-05.txt excerpt below is the only 
statement of ‘why’ and I think it is insufficient.  As a courtesy to 
the reader, a short summary of how this fits into the TAPS design 
process would be helpful.  Specifically, I think we need to say that 
this document captures an intermediate stage of the design process, a 
snapshot in time analysis of the IETF transport protocols, and is being 
published as an RFC to document the authors’ & working group’s 
analysis generating a set of transport abstractions that can be exported 
in the TAPS API.  (You’ll probably be able to phrase it better. :)

>    The list of primitives, events and transport features in this
>    document is strictly based on the parts of protocol specifications
>    that describe what the protocol provides to an application using it
>    and how the application interacts with it.  Together with an 
> overview
>    of the services provided by IETF transport protocols and congestion
>
>
>
> Welzl, et al.           Expires November 25, 2017               [Page 
> 3]
> 
> Internet-Draft             Transport Services                   May 
> 2017
>
>
>    control mechanisms [RFC8095] and an analysis of UDP and UDP-Lite
>    [FJ16], it provides the basis for the minimal set of transport
>    services that end systems should support
>    [I-D.draft-gjessing-taps-minset].

Regarding the above, we probably want to say “end systems supporting 
TAPS should implement” or something.  Saying end systems “should 
support” this set of services is a strong statement and we probably 
shouldn’t say it.

Probably also want draft-ietf-taps-transports-usage to point to 
draft-ietf-taps-transports-usage-udp in the introduction so it’s clear 
to the reader that these are a set.

—aaron

---

From: Michael Welzl <[email-masked]>
Date: Sat, 24 Jun 2017 00:19:58 +0200

Dear Tommy,

Thanks a lot for your comments! Very helpful - and painful too  :-)  to fix the messy style (lower case / upper case / ..), which originated from me just copy+pasting it from the various source RFCs… I should have fixed this long ago, I think it looks much better now - so thanks indeed for making me do this!

About MPTCP, that’s also done (mention that everything applies to both - I actually did say so for an earlier “pass” but now I added it for pass 3 too).

Cheers,
Michael

> On Jun 4, 2017, at 10:40 PM, Tommy Pauly <[email-masked]> wrote:
> 
>> On May 30, 2017, at 3:14 AM, Brian Trammell (IETF) <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> hi Aaron, all,
>> 
>>> On 29 May 2017, at 18:30, Aaron Falk <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Dear TAPS working group:
>>> 
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: Michael Welzl <[email-masked]>
Date: Sat, 24 Jun 2017 00:22:09 +0200

Dear Aaron,

Thanks a lot for your comments!

In line:

> On Jun 19, 2017, at 8:20 PM, Aaron Falk <[email-masked]> wrote:
> 
> IMO, the doc looks good and should be published. See below for a couple of comments that should be addressed before submission for AD review.
> 
> For both docs, the introduction (plus the appendix) does a good job of talking about ‘what’ is in the doc but the draft-ietf-taps-transports-usage-05.txt excerpt below is the only statement of ‘why’ and I think it is insufficient. As a courtesy to the reader, a short summary of how this fits into the TAPS design process would be helpful. Specifically, I think we need to say that this document captures an intermediate stage of the design process, a snapshot in time analysis of the IETF transport protocols, and is being published as an RFC to document the authors’ & working group’s analysis generating a set of transport abstractions that can be exported in the TAPS API. (You’ll probably be able to phrase it better. :)
> 
Done in the intro, and also added a sentence to the abstract.

> and how the application interacts with it. Together with an overview
> Welzl, et al. Expires November 25, 2017 [Page 3]
> 
> Internet-Draft Transport Services May 2017
> 
> Regarding the above, we probably want to say “end systems supporting TAPS should implement” or something. Saying end systems “should support” this set of services is a strong statement and we probably shouldn’t say it.
> 
Absolutely agree, indeed I didn’t mean to recommend that all the world’s end systems be changed (though I’d love that  ;-)  ).  Fixed.

> Probably also want draft-ietf-taps-transports-usage to point to draft-ietf-taps-transports-usage-udp in the introduction so it’s clear to the reader that these are a set.
> 
Agree, done (I think I did already but now the citation is in a more obvious position I think)

Cheers,
Michael

> On the Usage of Transport Features Provided by IETF Transport Protocols <https://www.ietf.org/internet-drafts/draft-ietf-taps-transports-usage-05.txt>
> Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP- Lite) Transport Protocols <https://www.ietf.org/internet-drafts/draft-ietf-taps-transports-usage-udp-03.txt>
> —aaron
>

---

From: "Aaron Falk" <[email-masked]>
Date: Mon, 26 Jun 2017 12:06:00 -0400

WGLC for these drafts has concluded.  While there were only a few 
comments on the final drafts, they were all constructive and positive.  
A significant amount of work and review has gone into the drafts 
creation by all the folks engaged in the working group so I’m not 
surprised at the minimal review discussion.  In my view, the docs are 
ready to publish, modulo a possible revision of the UDP doc.

We need a shepherd to take these drafts through the publication process. 
  Ideally, it won’t be a wg chair or author.  Would someone step 
forward?

—aaron