Hi, Michael, On Fri, Aug 25, 2017 at 12:45 PM, Michael Welzl <[email protected]> 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 < > [email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/taps
