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

[Michael Tuexen <[e-mail]>]

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]
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
>