Re: [tsvwg] Mirja Kühlewind's Yes on draft-ietf-tsvwg-sctp-ndata-12: (with COMMENT)

[Michael Tuexen <[e-mail]>]

> On 28. Aug 2017, at 17:07, Mirja Kühlewind <[e-mail]> wrote:
> 
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-tsvwg-sctp-ndata-12: Yes
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Mostly editorial comments:
Hi Mirja,

thanks you your comments. See my replies in-line.

Best regards
Michael
> 1) Why, after all, is SSN renamed to MID? I understand that the MID was
> extended to 32 bit and that the name might be more appropriate but I still find
> it confusing given both fields have the same semantics. Maybe it would help to
> point this out more explicitly in the document.
They only have the same semantics for ordered user messages. For unordered user
messages, the SSN is not defined. So it has a different semantics and using
the name "Stream Sequence Number" for unordered user messages does not make
sense. So the name was changed.

This is stated in the description of the MID:

      The MID is the same for all fragments of a user message, it is
      used to determine which fragments (enumerated by the FSN) belong
      to the same user message.  For ordered user messages, the MID is
      also used by the SCTP receiver to deliver the user messages in the
      correct order to the upper layer (similar to the SSN of the DATA
      chunk defined in [RFC4960]). 

The change of the size was done to overcome the limitations of only
having about 2**15 outstanding user messages per stream when not using the TSN
anymore.
> 
> 2) It could be helpful for the reader to also name the I and the U bits in
> section 2.1; especially the U bit could be referenced when MID is explained.
Since Eric brought up a similar comment, I have added text to 2.1 also describing
the "old" fields explicitly and only by referring to RFC 4960 and RFC 7053.
> 
> 3) Should there maybe be a recommendation that re-assotiating without
> interleaving support could be tried if a ABORT message is received. I guess
> that failure case could occur if the negation was altered in the network and
> one end thinks it support interleaving but the other not...?
Hmm. You mean middleboxes changing parameters of INIT- and INIT-ACK chunks
in an inconsistent way... I haven't seen such boxes up to now and we haven't
put in protocol mechanisms in the negotiation of extensions to deal with
this. Not sure why we should start doing this with this extension.

In the case of WebRTC, SCTP is running on top of DTLS and there should really
be no changes to SCTP packets made by middleboxes.
> 
> 4) Related to my first point: I guess you only need a new I-FORWARD-TSN chunk
> because you use MID instead of SSN. This seem to me that you just took the
> opportunity to make this change with this extension but then it should maybe be
> the spell out as a 'separate' change/improvement in the intro.
I'm not sure I understand what you are wanting to say. The FORWARD-TSN chunk
contains the SSN, which is gone from the I-DATA chunk, we had to change it.
> 
> 5) Really a nit but hard to read otherwise; you really need to use a comma here
> (sec 1.1): OLD "If I-DATA support has been negotiated for an association
>   I-DATA chunks are used for all user-messages."
> NEW
> "If I-DATA support has been negotiated for an association,
>   I-DATA chunks are used for all user-messages.“
Fixed.
> 
>