Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata as PS, closes 22 Dec 2016

[Michael Tuexen <[e-mail]>]

> On 21 Mar 2017, at 07:16, Proshin, Maksim <[e-mail]> wrote:
> 
> Hi Michael,
> 
> Basically I'm ok with all your answers and updates. 
> I don't have any major comments but I have a few proposals below inline (by [Maksim] tag).
Hi Maksim,

see my comments in-line. I've removed issues which are resolved.

Best regards
Michael
> 
> BR, Maksim
> 
> 
> -----Original Message-----
> From: Michael Tuexen [mailto:[e-mail]] 
> Sent: Monday, March 13, 2017 14:00
> To: Proshin, Maksim <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata as PS, closes 22 Dec 2016
> 
>> On 19 Dec 2016, at 17:16, Proshin, Maksim <[e-mail]> wrote:
>> 
>> Hi,
>> 
>> Thanks for the document! Please find below some comments. Only major comments are included while editorial/minor comments have been sent directly to Michael.
> Hi Maxim,
> 
> thanks a lot for the review. I addresses the minor comments and responded to your mail.
> See my comments in-line.
> 
> Best regards
> Michael
>> 
>> 1. Section 1.1: "DATA chunks are not
>>  permitted when I-DATA support has been negotiated."
>> What exactly does it mean for implementation (both sending and 
>> receiving sides)? I think to avoid any problems with the sending side 
>> it should be "MUST NOT" in the sentence. For the receiving side I 
>> suppose it means stop processing of the packet and silently discard 
>> all further chunks in the packet, right? I think this should be 
>> clearly stated. It could also be good to clearly state that after 
>> association
> I think it is clearly stated in 2.2.1:
> 
> If I-DATA support has been negotiated for an association, I-DATA chunks MUST be used for all user messages and DATA-chunks MUST NOT be used. If I-DATA support has not been negotiated for an association, DATA chunks MUST be used for all user messages and I-DATA chunks MUST NOT be used.
> 
> [Maksim] Ok, I agree that Section 2.2.1 clearly explains it for the sender. Can the same be explained for the receiver?
> 
> So if these rules are violated, I think sending an ABORT with protocol violation might be appropriate.
> [Maksim] Ok. Can it be clearly stated (e.g. in 2.2.1)? I mean it would be good to state that such case should be treated as a protocol violation. I also wonder that it should be mentioned that the restart case is different and should not be treated as a violation. 
> 
>> restart which was with DATA previously but became with I-DATA after the restart, SCTP still may receive packets with DATA and they should be silently discarded due to VTag mismatch following the rules of Section 8.5. from RFC4960 (I suppose this is important to avoid any "protocol violation" reaction). 
> Sure. But this is normal restart behavior.
> [Maksim] The reason I've asked it is because the statement is that this is "permitted" while in the restart case it is still possible to receive DATA while I-DATA was already negotiated.
>> 
>> 
>> 6. Section 4.1: 
>> MID is 32 bits while SSN is 16 bits so why a new SCTP Receive Information Structure cannot be introduced instead of using the existing one?
> One could add such a structure, but is it needed? I don't see a use-case...
> [Maksim] Isn't the drawback of the current approach is that 16 bits are lost?
>> If the new SCTP Receive Information Structure is introduced then a new message receive function should also be introduced (instead of recv_msg() ). Is that the main problem?
> recvmsg() is generic. It doesn't need to be changed. You would add another CMSG.
>> Of course, it would also be a problem if the interleaving functionality requires enabling only on the sender side (see the next comment).
> No, it is required to be enabled on both sides.
>> 
>> 
>> 7. Section 4.3.1:
>>  User message interleaving is disabled per default.
>> I'm not sure about it. First of all I think it should be clearly stated what does it mean for the sender and for the receiver.
>> If the intention was that I-DATA is included to INIT and INIT ACK only when the user enabled this functionality then I think this is not a good way because then it impacts not only the sender but also the receiver. 
>> In other words, if the feature is disabled by default on both sides while SCTP on both sides support it then it is not enough to just enable it on one side, it requires enabling it on the other side.  
> Exactly. I think this is stated in the first sentence of 2.2.1.
> [Maksim] I think it is not clearly stated in the document. "Supported" does not really mean "enabled". I would clearly state that this functionality should be enabled on both sides and only in this case it could be successfully negotiated. Especially it is important to state for the receiver side because Section 2.2.1 has the following statement "A sender MUST NOT use the I-DATA chunk unless the user has requested its use (e.g. via the socket API, see Section 4.3)." 
>> 
>> 9. Section 6: In case of DTLS over SCTP support of the message interleaving functionality may increase the risk of receiving messages with new epoch after ChangeCipherSpec message and before Finished message.
> Possibly. But implementations have to deal with it anyway. So what is the point?
> [Maksim] Mainly my point was that it could be clarified so that future SCTP implementations of this draft/RFC supporting DTLS could consider it.