Skip to main content

Last Call Review of draft-ietf-tsvwg-sctp-ndata-12
review-ietf-tsvwg-sctp-ndata-12-opsdir-lc-winter-2017-08-16-00

Request Review of draft-ietf-tsvwg-sctp-ndata
Requested revision No specific revision (document currently at 13)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-08-25
Requested 2017-08-10
Authors Randall R. Stewart , Michael Tüxen , Salvatore Loreto , Robin Seggelmann
Draft last updated 2017-08-16
Completed reviews Secdir Last Call review of -12 by Scott G. Kelly (diff)
Genart Last Call review of -12 by Stewart Bryant (diff)
Opsdir Last Call review of -12 by Stefan Winter (diff)
Assignment Reviewer Stefan Winter
State Completed
Review review-ietf-tsvwg-sctp-ndata-12-opsdir-lc-winter-2017-08-16
Reviewed revision 12 (document currently at 13)
Result Has Issues
Completed 2017-08-16
review-ietf-tsvwg-sctp-ndata-12-opsdir-lc-winter-2017-08-16-00
One issue:

The chapter IANA considerations mentions four bits to be registered: E,B,U,I.
In the main body, only three of those are actually defined and used (End of
fragmented message, Beginning of fragmented message, Unordered/Ordered
message). Please add a definition of the I bit or remove the IANA registration
request for that bit.

And the rest are only musings not needing any action if the authors don't want
to action on them:

The introduction presents a good use case, quoting: "e.g., when the
transmission of an urgent
   message is blocked from transmission because the sender has started
   the transmission of another, possibly large, message".

The later queueing example in figure 1 has three SIDs being queued
simultanseously. It is not clear which of those "has already started" and which
are the important ones being delayed. For a better understanding of the reader,
it might be useful to revise the figure so that the head-of-line blocking
happens for SID 1 because transmission of  0 and 2 has already started (and
declare SID 1 to be the "important" message). The ASCII art would just have to
indent SID 1 content a bit (placing 0 and 2 earlier in time), and the resulting
serialisation would then put all the SID 1 messages at the very end, when 0 and
2 have been completely submitted (right?).

In 2.2.3, is there any particular reason why the "protocol violation" error
cause is only a MAY? As it enables debugging on the remote end, a SHOULD seems
useful.