Subject: [tsvwg] Comments on draft-ietf-tsvwg-sctp-ndata-07.

From: G Fairhurst <[email-masked]>
Date: Sat, 24 Sep 2016 10:22:24 +0100

With no WG Chair hat, I have the following editorial feedback that you 
may like to consider. These comments are on 
draft-ietf-tsvwg-sctp-ndata-07. I shall separately ask questions as the 
document shepherd.

Gorry

---

Editorial comments:
—
I see the document as having several parts, a para at the end of section 
1 that explains these major parts would have been a welcome addition to 
the document.
—
Please expand “MTU” on first usage:
/MTU sized message./
—
Replace /which/ by /that/
/applications which might/
—
/might send very large messages over SCTP/
- I’m curious whether the /very/ is really necessary (could we delete?), 
even a just a “large” message can benefit? (see next para)
—
/are now sent over SCTP/
- The word /now/ may be confusing, when the spec in this ID will define 
a part of SCTP. Can you refer to a spec - RFC4960? Or say “Prior to 
publication of this specification, SCTP…”
—
/a form of
sender side head of line blocking becomes created within the
protocol/
- maybe this could be clearer, and perhaps even include an example to be 
sure the reader understands the benefit,
/can result in a form of
sender side head of line blocking (e.g., when transmission of an urgent 
message is blocked from transmission because the sender has started 
transmission of another, possibly larger, message)./
—
/an scheduler implies/
to
/a scheduler implies/
—
Please expand “SACK” on first usage:
/SACK chunks/
—
/ The MID is also used for ensuring ordered delivery, therefore 
replacing the stream sequence number. /
- the word “replacing” is ambiguous with respect to whether the stream 
sequence number is still set, etc. can we say “omitting” or say 
something that these fields are no longer present and equivalent 
functions are provided by …?
—
/Therefore, the head of line
blocking caused by the original design is avoided./
- I’m not sure this explains how this mechanism does this - I think this 
sentence could be re-worded, or even just omitted.
—
/and no DATA chunks./
- Does this mean
/. DATA chunks are not permitted when this has been negotiated./
—
Can the figures be referenced in section 1 also be used to illustrate 
some of the scheduler descriptions in section 3 (e.g., by backwards 
reference) ?
—
/ this field is NOT touched/
— is touched a term used elsewhere in SCTP? If this is not a 
widely-understood term please replace by “updated” or “read” or some 
similar combination of terms.
—
/a sender MAY fragment
multiple user message, each of them on different streams./
- insert /s/ after message.
—
/SCTP packet containing a I-DATA chunk/
should be
/SCTP packet containing an I-DATA chunk/
—
/then the receiver MUST use the FSN
for reassembly of the message and not the TSN/
- perhaps it may be clearer to explicitly say:
/then a receiver that has negotiated use of I-Data for a stream MUST use 
the FSN
for reassembly of the message and not the TSN/
—
/An ordered or unordered fragmented message
is thus identified by not having both bits set./
- I can’t unravel this sentence.
- Is this perhaps clearer written in this style:
/A message may be identified as being … by seeing that both bits have 
been set./
—
/MUST be reset to 0 correspondingly./
- I’m not sure what “correspondingly” means here, could this be omitted?
—
/it should be noted
that the implementation of [RFC6525] needs to handle this./
- understood, but this kind of suggests all RFC6525 implementations need 
to do this… is it true? is it all implementations of I-Data need this?
—
/ The streams schedulers/
- please change to:
/ The stream schedulers/
—
Section 4.2 uses the term /and being deprecated/.
- It is not evident from reading this what that means.
—
/EOR/
- Please expand when first mentioned.
—-
I think section 6 (security consideration) could usefully note that 
applications need to consent to the use of out-of-sequence delivery. 
This is accomplished by applications needing to enable the extension via 
the transport API.