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

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 19 Mar 2013 18:49:20 +0000

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)
[email-masked]

---

From: "Black, David" <[email-masked]>
Date: Tue, 19 Mar 2013 22:57:21 -0400

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.

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:

   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"

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"

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"

Section 8: Please tell IANA which registry to use by including the
name of the registry.

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

Thanks,
--David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 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
> 
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 22 Mar 2013 12:19:40 +0000

This email announces the start of a working group last call for
draft-ietf-tsvwg-sctp-udp-encaps-14, "UDP Encapsulation of SCTP Packets 
for End-Host to End-Host Communication".  This document has completed an 
IETF LC and was updated after IESG review. This is now thought to be 
ready to proceed to be published as a PS by RFC-Ed. Please send any 
comments to the TSVWG list.

The draft is available at:
http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-udp-encaps-14

Summary of main changes:

* Clarification that the focus is on encapsulation between SCTP endpoints.

* UNSAF considerations added.

* Change from UDP checksum MUST be computed for SCTP/UDP/IPv6 to UDP 
checksum SHOULD be computed for SCTP/UDP/IPv6 to reflect recently 
changed UDP/IPv6 checksum handling, with rationale provided.

A diff between the version submitted to the IESG and the current version 
can be viewed using:
http://tools.ietf.org/rfcdiff?url1=draft-ietf-tsvwg-sctp-udp-encaps-07.txt&url2=draft-ietf-tsvwg-sctp-udp-encaps-14.txt

This shortened last call will end on Friday 5th April 2013.

Emails saying "I support" or "I don't support" publication with these 
changes are also most  helpful in judging the WG consensus.

Please note another running SCTP WGLC also below.

James and Gorry
(TSVWG Chairs)
[email-masked]

-------- Forwarded Message --------

James, David and Gorry
(TSVWG Chairs)
[email-masked]

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 23 Mar 2013 14:19:11 +0100

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

> 	that this bit should be set to 0 by the sender and ignored
Done in CVS. Will be in the next revision.
> 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>
> Also an editorial nit in the above - "in case of" -> "for"
Done in CVS. Will be in the next revision.
> "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.

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

>   a malicious sender can force its peer to send packets containing a SACK
Done in CVS. Will be in the next rev.

---

From: "Black, David" <[email-masked]>
Date: Mon, 25 Mar 2013 18:27:38 -0400

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

> From: Michael Tuexen [mailto:[email-masked]]
> Sent: Saturday, March 23, 2013 9:19 AM
> To: Black, David
> Cc: [email-masked]; tsvwg WG
> Subject: Re: [tsvwg] WGLC Announcement for draft-ietf-tsvwg-sctp-sack-
> immediately-02: 19th March 2013
> 
> Hi David,
>

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 26 Mar 2013 09:32:25 +0100

> 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