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

["Black, David" <[e-mail]>]

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?

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