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