Stream Control Transmission Protocol (SCTP) Partial Reliability Extension
RFC 3758

Note: This ballot was opened for revision 03 and is now closed.

(Allison Mankin) Yes

(Thomas Narten) (was Discuss) Yes

Comment (2003-12-18)
No email
send info
Nits:

>    Hereafter, we use the notation "PR-SCTP" to refer to the SCTP
>    protocol extended as defined in this document.

Spell out "partially reliable" above so folk make the connection with
PR.

>    Comparisons and arithmetic on TSNs are governed by the rules in
>    Section 1.6 of RFC2960 [3].

expand TSN on first usage.

>   services as required.  Each such service may be proposed as a
>   separate new informational RFC.

Better to drop "informational". Point is to publish each one as
separate document. The exact type of document doesn't need to be
specified here, though I suspect info will be the normal case. But it
isn't a requirement.

same comment applies elsewhere in document.


>    Rodriguez, Ian Rytina, Chip Sharp, and others for their comment.s

s/.s/s./

>    When a receiver of an INIT detects a Forward-TSN-Supported parameter,
>    and does not support the Forward-TSN chunk type, the receiver SHOULD
>    treat this parameter as an invalid or unrecognized parameter and
>    respond to the data sender with an unrecognized parameter in the
>    INIT-ACK, following the rules defined in Section 3.3.3 of RFC2960
>    [3].
> 
>    When a receiver of an INIT-ACK detects a Forward-TSN-Supported
>    parameter, and does not support the Forward-TSN chunk type, the
>    receiver SHOULD treat this parameter as an invalid or unrecognized
>    parameter and respond to the data sender with an unrecognized
>    parameter error, following the rules defined in Section 3.3.3 of
>    RFC2960 [3]. This error SHOULD be reported in an ERROR chunk bundled
>    with the COOKIE-ECHO.

Seems odd for this document to seem to be saying what to do if you
don't understand the new extensions (that is what I intepret when I
see MUST langague like the above). I suspect the text that is here is
just being copied verbatim from the base SCTP spec. It would be better
to make to make it clear that this is already the required behavior
per 2960, and either quote the text (for info) or just point to the
other document.

(Jon Peterson) Yes

(Harald Alvestrand) No Objection

(Steven Bellovin) No Objection

Comment (2004-02-19)
No email
send info
-

(Margaret Cullen) No Objection

(Bill Fenner) No Objection

(Ned Freed) No Objection

(Ted Hardie) (was Discuss, No Objection) No Objection

Comment (2003-12-16)
No email
send info
Section 3.6 says:

   Whenever a DATA chunk arrives with the 'U' bit set to '0' (indicating
   ordered delivery) and is out of order, the receiver must hold the
   chunk for reordering. Since it is possible with PR-SCTP that a DATA
   chunk being waited upon will not be retransmitted, special actions
   will need to be taken upon the arrival of a FORWARD TSN.

   In particular, during processing of a FORWARD TSN, the receiver MUST
   use the stream sequence information to examine all of the listed
   stream reordering queues, and immediately make available for delivery
   stream sequence numbers earlier than or equal to the stream sequence
   number listed inside the FORWARD TSN.

Does the U bit here have a secondary expectation that when ordering is
requested, eventual delivery will be better than a drop?  If so, is there
any way to indicate that what you want is ordered delivery, but drop
CHUNKS not yet delivered if the FORWARD TSN is received?

In Section 4, can I suggest "standardized in an informational RFC." be replaced
with "documented in an Informational RFC?"  (By the way, would we object
to someone asking for standards track to one that had been specified in
a WG?)

Lastly, the document seems to make the design choice that using something
liked "timed reliability" is something that the sender decides based on
the availability of Forward TSN as a primitive, and that there is no sense in
which the receiver ought to decide whether to support Forward TSN based
on which of these PR-SCTP services it would be used with.  Fair enough, but
if there is motivational text laying about that could describe that design decision
process, it would be valuable to add it.  It's probably not worth the sweat of
cooking up, though, if it is not available already.

(Russ Housley) No Objection

(David Kessens) No Objection

(Bert Wijnen) No Objection

Comment (2003-12-18 for -)
No email
send info
From OPS Directorate (Pekka)

Nits
Abstract 
   This memo describes an extension to the Stream Control Transmission
   Protocol (SCTP) RFC2960 [3] that allows an SCTP endpoint to signal to
 
==> remove the refs from the abstract.

   [1]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
        9, RFC 2026, October 1996.
                                                                                                                                       
==> this can be removed, isn't even being used.

8. IANA Considerations
                                                                                                                                       
   One new chunk type is added to SCTP (192) by this document.
                                                                                                                                       
   One new parameter type code is defined by this document to be added
   to SCTP (49152).

==> well, technically, IANA is registering these codes and types, not 
you guys :-).  So these should be reworded to be like: "IANA is 
requested to assign a new chunk type to SCTP; using "192" is 
recommended".  But I'm not sure if this is really needed :-)

    Rodriguez, Ian Rytina, Chip Sharp, and others for their comment.s
                                                                                                                                       
==> s/.s/s./

(Alex Zinin) No Objection