Re: [Taps] AD review for draft-ietf-taps-transports-usage-06

[Spencer Dawkins at IETF]

Hi, Michael,

On Fri, Aug 25, 2017 at 12:45 PM, Michael Welzl  wrote:

> Hi!
>
> Thanks a lot - I addressed them all. Details below, in line;
>

That all looks fine to me. I'll be putting this and the UDP draft out for
Last Call together, if that works for the chairs.

Spencer


> cheers,
> Michael
>
>
> On Aug 24, 2017, at 10:18 PM, Spencer Dawkins at IETF <
> spencerdawkins.i...@gmail.com> wrote:
>
> These are all editorial.
>
> Thanks,
>
> Spencer
>
> A nit - in this text,
>
>Transport Protocol:  an implementation that provides one or more
>   different transport services using a specific framing and header
>   format on the wire.
>
> one path through the "or" statement says "provides one different header",
> which reads oddly. Perhaps s/different//?
>
>
> done.  Note that this definition is already published in RFC 8095, but I
> think it’s a minor issue - just easier to read with your fix, and surely
> not a semantic difference, so I did as you suggest.
>
>
> This text
>
>   The TAPS working group intends to describe an (abstract) interface
>for applications to make use of Transport Services, such that
>applications are no longer directly tied to a specific protocol.
>
> Is pointing to the TAPS working group, which will conclude someday. It’s
> probably better to point to “this specification”, and it’s probably good to
> think of the text as appearing in an RFC, so “intends to describe” is
> probably better as “describes” (at Last Call time, intentions don’t matter).
>
>
> Done  (replacements as you proposed)
>
>
> This text
>
>Transport protocols
>provide communication between processes that operate on network
>endpoints, which means that they allow for multiplexing of
>communication between the same IP addresses, and normally this
>multiplexing is achieved using port numbers.
>
> Confused me - are any of the transport protocols you’re describing not
> using port numbers for multiplexing? If not, s/normally//
>
>
> Done
>
>
> A nit - you have an “SCPT” in Section 3.3.
>
>
> Thanks, fixed
>
>
> In this text,
>
>The following three removed limitations directly
>translate into transport features that are visible to an application
>using SCTP: 1) it allows for preservation of message delineations; 2)
>these messages, do not require to be in order or reliably transferred
>unless the application wants it; 3) multi-homing is supported.
>
> I’m not parsing the description labeled “2)”. I THINK you’re saying “it
> does not provide in-order or reliable delivery unless the application wants
> that”, but I’m not sure.
>
>
> You’re right, and I replaced my item 2) with your text proposal
>
>
> In this sentence,
>
>   Section 10 of the SCTP base protocol specification [RFC4960]
>specifies the interaction with the application (which this RFC calls
>the "Upper Layer Protocol" (ULP)).
>
> Your draft is going to be the default for “this RFC” when it’s published
> as an RFC.  Better to say “which SCTP calls”, I think.
>
>
> Done
>
>
> In this sentence,
>
>The functionality exposed to the ULP through the all these APIs is
>considered here.
>
> “The all these” is garbled.
>
>
> Fixed.
>
> Cheers,
> Michael
>
>
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] AD Evaluation on the relationship between draft-ietf-taps-transports-usage-06 and draft-ietf-taps-transports-usage-udp-04

[Spencer Dawkins at IETF]

Hi, Michael,

On Fri, Aug 25, 2017 at 12:47 PM, Michael Welzl  wrote:

>
> On Aug 24, 2017, at 10:24 PM, Spencer Dawkins at IETF <
> spencerdawkins.i...@gmail.com> wrote:
>
> Just to make these documents a bit more digestible by reviewers, ADs, and
> readers, who will almost certainly be reading them as a set ...
>
> I'm OK with the separation of the Pass 1 analysis of UDP(-lite) into a
> separate draft, but I wish the relationship was a little clearer. It seems
> like https://tools.ietf.org/html/draft-ietf-taps-transports-
> usage-06#section-3.4 has more text describing UDP(-lite) than it needs,
> if it's just going to say "The set of Pass 1 primitives for UDP and
> UDP-Lite is documented in [FJ16].".
>
> If this makes sense to the working group, that description of UDP could be
> integrated into https://tools.ietf.org/html/draft-ietf-taps-transports-
> usage-udp-04#section-3, which only has a one-sentence description of UDP
> itself before beginning its analysis.
>
>
> I agreed with the authors of the other document that this is the right way
> forward. This text in the -usage draft consisted of 3 paragraphs, followed
> by the sentence that you quote above (“The set of …”). I removed these
> preceding three paragraphs now.
>
>
> Is there any chance that each document could provide a pointer to the
> other document, in the Abstract and Introduction sections, and be clearer
> about the relationship there?
>
>
> While there was a pointer to the other document in the intro of the -usage
> draft already, I agree it wasn’t very clear, sorry!
> I now added, to both the intro and the abstract:
>
> "For UDP and UDP-Lite, the first step of the protocol analysis -- a
> discussion of relevant RFC text -- is documented in [FJ16].”
>
> Thanks a lot for your review!
>
> Cheers,
> Michael
>

Oh, thank you! The fast path to IESG approval is to confuse the ADs as
little as possible :-)

Spencer
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] AD Evaluation on the relationship between draft-ietf-taps-transports-usage-06 and draft-ietf-taps-transports-usage-udp-04

[Michael Welzl]

> On Aug 24, 2017, at 10:24 PM, Spencer Dawkins at IETF 
>  wrote:
> 
> Just to make these documents a bit more digestible by reviewers, ADs, and 
> readers, who will almost certainly be reading them as a set ...
> 
> I'm OK with the separation of the Pass 1 analysis of UDP(-lite) into a 
> separate draft, but I wish the relationship was a little clearer. It seems 
> like 
> https://tools.ietf.org/html/draft-ietf-taps-transports-usage-06#section-3.4 
>  
> has more text describing UDP(-lite) than it needs, if it's just going to say 
> "The set of Pass 1 primitives for UDP and UDP-Lite is documented in [FJ16].". 
> 
> If  this makes sense to the working group, that description of UDP could be 
> integrated into 
> https://tools.ietf.org/html/draft-ietf-taps-transports-usage-udp-04#section-3 
> ,
>  which only has a one-sentence description of UDP itself before beginning its 
> analysis.

I agreed with the authors of the other document that this is the right way 
forward. This text in the -usage draft consisted of 3 paragraphs, followed by 
the sentence that you quote above (“The set of …”). I removed these preceding 
three paragraphs now.


> Is there any chance that each document could provide a pointer to the other 
> document, in the Abstract and Introduction sections, and be clearer about the 
> relationship there?

While there was a pointer to the other document in the intro of the -usage 
draft already, I agree it wasn’t very clear, sorry!
I now added, to both the intro and the abstract:

"For UDP and UDP-Lite, the first step of the protocol analysis -- a discussion 
of relevant RFC text -- is documented in [FJ16].”

Thanks a lot for your review!

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] AD review for draft-ietf-taps-transports-usage-06

[Michael Welzl]

Hi!

Thanks a lot - I addressed them all. Details below, in line;

cheers,
Michael


> On Aug 24, 2017, at 10:18 PM, Spencer Dawkins at IETF 
>  wrote:
> 
> These are all editorial.
> 
> Thanks,
> 
> Spencer
> 
> A nit - in this text,
> 
>Transport Protocol:  an implementation that provides one or more
>   different transport services using a specific framing and header
>   format on the wire.
> 
> one path through the "or" statement says "provides one different header", 
> which reads oddly. Perhaps s/different//?

done.  Note that this definition is already published in RFC 8095, but I think 
it’s a minor issue - just easier to read with your fix, and surely not a 
semantic difference, so I did as you suggest.


> This text 
> 
>   The TAPS working group intends to describe an (abstract) interface
>for applications to make use of Transport Services, such that
>applications are no longer directly tied to a specific protocol.
> 
> Is pointing to the TAPS working group, which will conclude someday. It’s 
> probably better to point to “this specification”, and it’s probably good to 
> think of the text as appearing in an RFC, so “intends to describe” is 
> probably better as “describes” (at Last Call time, intentions don’t matter).

Done  (replacements as you proposed)


> This text
> 
>Transport protocols
>provide communication between processes that operate on network
>endpoints, which means that they allow for multiplexing of
>communication between the same IP addresses, and normally this
>multiplexing is achieved using port numbers.
> 
> Confused me - are any of the transport protocols you’re describing not using 
> port numbers for multiplexing? If not, s/normally//

Done


> A nit - you have an “SCPT” in Section 3.3.

Thanks, fixed


> In this text,
> 
>The following three removed limitations directly
>translate into transport features that are visible to an application
>using SCTP: 1) it allows for preservation of message delineations; 2)
>these messages, do not require to be in order or reliably transferred
>unless the application wants it; 3) multi-homing is supported.
> 
> I’m not parsing the description labeled “2)”. I THINK you’re saying “it does 
> not provide in-order or reliable delivery unless the application wants that”, 
> but I’m not sure.

You’re right, and I replaced my item 2) with your text proposal


> In this sentence,
> 
>   Section 10 of the SCTP base protocol specification [RFC4960]
>specifies the interaction with the application (which this RFC calls
>the "Upper Layer Protocol" (ULP)). 
> 
> Your draft is going to be the default for “this RFC” when it’s published as 
> an RFC.  Better to say “which SCTP calls”, I think.

Done


> In this sentence, 
> 
>The functionality exposed to the ULP through the all these APIs is
>considered here.
> 
> “The all these” is garbled.

Fixed.

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

[Taps] I-D Action: draft-ietf-taps-transports-usage-07.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Services WG of the IETF.

Title   : On the Usage of Transport Features Provided by IETF 
Transport Protocols
Authors : Michael Welzl
  Michael Tuexen
  Naeem Khademi
Filename: draft-ietf-taps-transports-usage-07.txt
Pages   : 50
Date: 2017-08-25

Abstract:
   This document describes how the transport protocols Transmission
   Control Protocol (TCP), MultiPath TCP (MPTCP), Stream Control
   Transmission Protocol (SCTP), User Datagram Protocol (UDP) and
   Lightweight User Datagram Protocol (UDP-Lite) expose services to
   applications and how an application can configure and use the
   features that make up these services.  It also discusses the service
   provided by the Low Extra Delay Background Transport (LEDBAT)
   congestion control mechanism.  The description results in a set of
   transport abstractions that can be exported in a TAPS API.  For UDP
   and UDP-Lite, the first step of the protocol analysis -- a discussion
   of relevant RFC text -- is documented in [FJ16].  XX RFC ED - PLEASE
   REPLACE [FJ16] WITH THE CORRECT RFC NUMBER XXX


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-taps-transports-usage-07
https://datatracker.ietf.org/doc/html/draft-ietf-taps-transports-usage-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-usage-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps