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

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 24 Aug 2017 15:18:11 -0500

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//?

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

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

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

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.

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.

In this sentence,

   The functionality exposed to the ULP through the all these APIs is

   considered here.

“The all these” is garbled.

---

From: Michael Welzl <[email-masked]>
Date: Fri, 25 Aug 2017 19:45:29 +0200

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 <[email-masked]> wrote:
> 
> These are all editorial.
> 
> Thanks,
> 
> Spencer
> 
> A nit - in this text,
> 
> 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.

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

> 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

> 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

> 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

> “The all these” is garbled.

Fixed.

Cheers,
Michael

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 25 Aug 2017 14:13:55 -0500

Hi, Michael,

> 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

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