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.