Re: [tsvwg] WGLC Announcement for draft-ietf-tsvwg-sctp-sack-immediately-02: 19th March 2013

[Michael Tuexen <[e-mail]>]

On Mar 25, 2013, at 11:27 PM, Black, David wrote:

> Hi Michael,
> 
> All of your proposed changes look fine to me, including not using "SHOULD" in 4.2.
> 
> Are you also going to pick up the new sentence in 4.1 below?
Sure. Sorry I missed that. Thank for drawing my attention to it.

Best regards
Michael
> 
> I'll trust you to get the IANA registry contents correct.
> 
> Thanks,
> --David
> 
>> -----Original Message-----
>> From: Michael Tuexen [mailto:[e-mail]]
>> Sent: Saturday, March 23, 2013 9:19 AM
>> To: Black, David
>> Cc: [e-mail]; tsvwg WG
>> Subject: Re: [tsvwg] WGLC Announcement for draft-ietf-tsvwg-sctp-sack-
>> immediately-02: 19th March 2013
>> 
>> Hi David,
>> 
>> thank you very much for your comments. I'll incorporate them
>> in the next revision as stated in detail below.
>> 
>> Best regards
>> Michael
>> On Mar 20, 2013, at 3:57 AM, Black, David wrote:
>> 
>>> Comments as an individual - <WG co-chair hat OFF>
>>> 
>>> The draft generally looks good - I have a bunch of minor comments.
>>> 
>>> End of Section 3 - I suggest adding a sentence about the new I-bit:
>>> 
>>> 	This bit was Reserved in RFC 4960 - RFC 4960 specified
>>> 	that this bit should be set to 0 by the sender and ignored
>>> 	by the receiver.
>> Done in CVS. Will be in the next revision.
>>> 
>>> Section 4.1 - The paragraph in this section describes an example of a
>>> situation in which it is appropriate to set the I-bit.  It needs an
>>> introductory sentence to say that it is an example, e.g.:
>>> 
>>> 	One example of a situation in which it may be desirable for
>>> 	an application to trigger setting of the I-bit involves the
>>> 	SCTP_SENDER_DRY_EVENT in the SCTP socket API [RFC6458].
>>> 
>>> Section 4.2 - Suggest "should" -> "SHOULD" in the following paragraph:
>> We don't use the normative text in the other use cases of this section.
>> So being consistent might be good. What about:
>> <t>If the association is in the SHUTDOWN-PENDING state, setting the I-bit
>> reduces the number of simultaneous associations for a busy server handling
>> short living associations.</t>
>>> 
>>>  If the association is in the SHUTDOWN-PENDING state, the I-bit should
>>>  be set.  This reduces the number of simultaneous associations in case
>>>  of a busy server handling short living associations.
>>> 
>>> Also an editorial nit in the above - "in case of" -> "for"
>> Done in CVS. Will be in the next revision.
>>> 
>>> Another editorial nit in the following:
>>> 
>>>  If an SCTP association supports the SCTP Stream Reconfiguration
>>>  extension defined in [RFC6525], the performance can be improved by
>>>  setting the I-bit when there are pending reconfiguration requests
>>>  requiring no outstanding DATA chunks.
>>> 
>>> "requiring" -> "that require that there be"
>> Done in CVS. Will be in the next rev.
>> Quick question: Instead of
>> 
>> ... that require that there be no outstanding DATA chunks.
>> 
>> should it be
>> 
>> ... that require that there are no outstanding DATA chunks.
>> 
>> 
>>> 
>>> Section 5.2:
>>> 
>>>  On reception of an SCTP packet containing a DATA chunk with the I-bit
>>>  set, the receiver SHOULD NOT delay the sending of the corresponding
>>>  SACK chunk and send it back immediately.
>>> 
>>> "SACK chunk and send it back immediately" -> "SACK chunk, i.e., the
>>> receiver SHOULD immediately respond with the corresponding SACK chunk"
>> Done in CVS. Will be in the next rev.
>>> 
>>> 
>>> Section 8: Please tell IANA which registry to use by including the
>>> name of the registry.
>> I agree, making is clearer is a good thing. So how about:
>> 
>> <t>Following the chunk flag registration procedure defined in
>> <xref target='RFC6096'/>, IANA should register a new bit, the I-bit, for
>> the DATA chunk. The suggested value is 0x08 and the reference should be
>> RFCXXXX.</t>
>> <t>This requires an update of the "DATA Chunk Flags" registry for SCTP:</t>
>> <texttable>
>> <preamble>DATA Chunk Flags</preamble>
>> <ttcol align='left'>Chunk Flag Value</ttcol>
>> <ttcol align='left'>Chunk Flag Name</ttcol>
>> <ttcol align='left'>Reference</ttcol>
>> <c>0x01</c> <c>E bit     </c> <c>[RFC4960]</c>
>> <c>0x02</c> <c>B bit     </c> <c>[RFC4960]</c>
>> <c>0x04</c> <c>U bit     </c> <c>[RFC4960]</c>
>> <c>0x08</c> <c>I Bit     </c> <c>[RFCXXXX]</c>
>> <c>0x10</c> <c>Unassigned</c> <c>         </c>
>> <c>0x20</c> <c>Unassigned</c> <c>         </c>
>> <c>0x40</c> <c>Unassigned</c> <c>         </c>
>> <c>0x80</c> <c>Unassigned</c> <c>         </c>
>> </texttable>
>> 
>>> 
>>> Section 9: Change start of paragraph to acknowledge new security
>>> consideration:
>>> 
>>> OLD
>>>  This document does not add any additional security considerations in
>>>  addition to the ones given in [RFC4960].  It should be noted that a
>>>  malicious sender can force its peer to send packets containing a SACK
>>> NEW
>>>  See [RFC4960] for general security considerations for SCTP.  In addition,
>>>  a malicious sender can force its peer to send packets containing a SACK
>>> END
>> Done in CVS. Will be in the next rev.
>>> 
>>> Thanks,
>>> --David
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>>>> Gorry Fairhurst
>>>> Sent: Tuesday, March 19, 2013 2:49 PM
>>>> To: tsvwg WG
>>>> Subject: [tsvwg] WGLC Announcement for draft-ietf-tsvwg-sctp-sack-
>> immediately-
>>>> 02: 19th March 2013
>>>> 
>>>> 
>>>> This email announces the start of a working group last call for
>>>> draft-ietf-tsvwg-sctp-sack-immediately-02.txt, "SACK-IMMEDIATELY
>>>> Extension for the Stream Control Transmission Protocol". This document
>>>> is now thought to be ready to proceed to be published as a PS. Please
>>>> send any comments to the TSVWG list.
>>>> 
>>>> The draft is available at:
>>>> http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-sack-immediately/
>>>> 
>>>> The last call will run for TWO weeks, ending Friday 5th April 2013.
>>>> 
>>>> Emails saying "I support" or "I don't support" publication are also most
>>>> helpful in judging the WG consensus. Please let us know if this draft
>>>> is useful and seems to provide the correct advice.
>>>> 
>>>> James, David and Gorry
>>>> (TSVWG Chairs)
>>>> [e-mail]
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
> 
>