Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2012-08-22
03 (System) post-migration administrative database adjustment to the Yes position for Thomas Narten
2004-05-28
03 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2004-05-28
03 Amy Vezza [Note]: 'RFC 3758' added by Amy Vezza
2004-05-26
03 (System) RFC published
2004-02-27
03 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2004-02-23
03 Amy Vezza IESG state changed to Approved-announcement sent
2004-02-23
03 Amy Vezza IESG has approved the document
2004-02-23
03 Amy Vezza Closed "Approve" ballot
2004-02-23
03 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza
2004-02-20
03 (System) Removed from agenda for telechat - 2004-02-19
2004-02-19
03 Thomas Narten [Ballot Position Update] Position for Thomas Narten has been changed to Yes from Discuss by Thomas Narten
2004-02-19
03 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2004-02-19
03 Steven Bellovin [Ballot comment]
-
2004-02-18
03 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2004-02-18
03 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Discuss by Ted Hardie
2004-02-12
03 Jon Peterson Placed on agenda for telechat - 2004-02-19 by Jon Peterson
2004-02-12
03 Jon Peterson State Changes to IESG Evaluation from IESG Evaluation::AD Followup by Jon Peterson
2004-02-12
03 Jon Peterson [Note]: 'Returning to try to clear DISCUSS.' added by Jon Peterson
2004-01-27
03 (System) New version available: draft-ietf-tsvwg-prsctp-03.txt
2003-12-18
03 Thomas Narten
[Ballot discuss]
Substantive:

>    At the initialization of the association, the sender of the INIT or
>    INIT ACK chunk shall include this …
[Ballot discuss]
Substantive:

>    At the initialization of the association, the sender of the INIT or
>    INIT ACK chunk shall include this OPTIONAL parameter to inform its
>    peer that it is able to support the Forward TSN chunk. The format of
>    this parameter is defined as follows:

Could be more clear. Is the INIT required to include it? Does the INIT
ACK only include it if the INIT did? I.e, Don't both sides need to
explicitly signal this capability before either side can use it?

Actually, this is made more clear later:

>    When an endpoint that supports the FORWARD TSN chunk receives an INIT
>    that does not contain the Forward-TSN-Supported Parameter, that
>    endpoint:
>
>    o  MAY include the Forward-TSN-Supported parameter in the INIT-ACK,
>
>    o  SHOULD record the fact that the peer does not support the FORWARD
>      TSN chunk,
>
>    o  MUST NOT send a FORWARD TSN chunk at any time during the
>      associations life,
>
>    o  SHOULD inform the upper layer, if the upper layer has requested
>      such notification.

But these rules seem odd (to me). Why would the ACK include the
Forward-TSN-supported if the INIT doesn't? Seems completely useless.
Second should is rather obvious. You need to record whether the other
side implements (if you do), so you know if you can send or not.

then...

> 7. Security Considerations
>
>    This document does not introduce any new security concerns to SCTP
>    other than the ones already documented in RFC2960 [3]. In particular
>    this document shares the same security issues as unordered data
>    within RFC2960 [3] identified by RFC3436 [5]. An application using
>    the PR-SCTP extension should not use transport layer security;
>    further details can be found in RFC3436 [5].

This option provides new way for a MITM (or other intruder) to
interfere with the packet flow. But this is the case in general
already, so the question is whether this makes things any worse than
things alread are.

I wonder about the following. If the sender SCTP indicates the
capability of supporting the new mode, and the receiver acknowledges
that it also supports the mode, _but_ neither the sender nor receiving
application (or maybe not both of them) requested the service, could
an intruder introduce messages that cause individual chunks to be
"abandoned" without either side noticing? This may not be a big attack
to worry about (compared to other types of attack), but it may be
preventable if:

  - it is only permitted if both SCTP endpoints negotiated the option

  - SCTP  only negotiates usage if the upper layer protocol has
    requested it do so.

Suggestion: make the following rules clear:

- INIT includes Forward-TSN-Supported only if application indicates
  it wants this feature
 
- INIT-ACK only includes Forward-TSN-Supported if it supports it AND
  upper layer application has requested its use, and in response to
  an INIT indicating support for the option.

>        Stream Sequence-N: 16 bit u_int
>
>          This field holds the sequence number associated with the stream
>          that was skipped. The stream sequence field holds the largest stream
>          sequence number in this stream being skipped.  The receiver of
>          the FWD-TSN's can use the Stream-N and Stream Sequence-N fields
>          to enable delivery of any stranded TSN's that remain on the stream
>          re-ordering queues. This field MUST NOT report TSN's corresponding
>          to DATA chunk that are marked as unordered. For ordered DATA
>          chunks this field MUST be filled in.

There seems to be an interesting edge case here. Suppose a data chunk
has been received, but not handed upwards, due to a missing sequence
number. But then a Forward-TSN arrives basically saying "we don't care
about this sequence number anymore". Should the receiver discard it?
(that would be correct behavior semantically -- the sender has
concluded it is no longer timely). Or it should it forward it up the
stack, since it has the data already. This document doesn't seem to
say what to do in this case. Indeed, the wording above might be
confusing as it talks about "enable delivery of stranded TSN".  I
assume this is NOT about the case I just described (but is that clear)
and is really trying to say that if the Forward-TSN moves the sequence
number to X, and chunk X has already been received, it can now be
handed upwards and the received sequence numbers adjusted
accordingly. It might be good to clarify these two points.


>      C3) If, after step C1 and C2, the "Advanced.Peer.Ack.Point" is
>          greater than the Cumulative TSN ACK carried in the received
>          SACK, the data sender MUST send the data receiver a FORWARD TSN
>          chunk containing the latest value of the
>          "Advanced.Peer.Ack.Point".
>
>          IMPLEMENTATION NOTE: It is an implemenation decision as to
>          which destination address is to be sent to, the only
>          restriction being that the address MUST be one that is
>          CONFIRMED.

Are there any corner cases here like if the a chunk is abandoned less
than one RTT after it was first queued? I.e., the above MUST might
lead to situations where you get several incoming SACKs that cause a
corresponding resent of the Forward-TSN chunk.

Actually, the somewhate MUST is contradicted later by MAYs, i.e.:

      A sender MAY even choose to delay the sending of the FORWARD TSN
      in the hope of bundling it with an outbound DATA chunk.

Maybe tweak the earlier wording with a pointer to the later text?

>    The new OPTIONAL parameter "forward tsn supported" is a boolean flag:
>
>    (0) false [default] indicates that FORWARD TSN is not supported by
>      the peer.
>
>    (1) true indicates that FORWARD TSN is supported by the peer.

Maybe a minor point, but shouldn't the semantics of this be "supported
by both sender and receiver"? That's what you care about, and if the
sender doesn't support this, it matters not if the peer does. Or, is
there some other way the sender determines whether the sending SCTP
supports this and  it is only allowed to request the feature if it
already knows its supported on the sender?

>    TR4) Before transmitting or retransmitting a message for which a TSN
>      is already assigned, the SCTP sender MUST evaluate the lifetime of
>      the message.  If the lifetime of the message is expired, the SCTP
>      sender MUST "abandon" the message, as per the rules specified in
>      Section 3.5 marking that TSN as eligible for forward TSN. Note
>      that this meets the requirement G1 defined in Section 4.3

I think TR4 should be split into two cases. In the case that a message
has not been transmitted yet, there is no need for "abandoning" the
messages as per this document. It can be handled using the previous
technique. This is important, because it means no messages go out on
the wire. Its only if the message has been transmitted once that one
needs to abandon...

Also, I think there should be some text/rules that say how to handle
the case of transmitting a DATA chunk (for the first time) it if is
clear that it would be scheduled for abandonment _before_ the RTT will
expire. I.e., its guaranteed to be "old" before the ACK comes
back. Naive implementations that don't think about this might do dumb
things. I don't think much text is needed, but it woudl be good to
notify implementors of the issue and what they should do about it.
2003-12-18
03 Thomas Narten
[Ballot comment]
Nits:

>    Hereafter, we use the notation "PR-SCTP" to refer to the SCTP
>    protocol extended as defined in this document. …
[Ballot comment]
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.
2003-12-18
03 Thomas Narten
[Ballot discuss]
Substantive:

>    At the initialization of the association, the sender of the INIT or
>    INIT ACK chunk shall include this …
[Ballot discuss]
Substantive:

>    At the initialization of the association, the sender of the INIT or
>    INIT ACK chunk shall include this OPTIONAL parameter to inform its
>    peer that it is able to support the Forward TSN chunk. The format of
>    this parameter is defined as follows:

Could be more clear. Is the INIT required to include it? Does the INIT
ACK only include it if the INIT did? I.e, Don't both sides need to
explicitly signal this capability before either side can use it?

Actually, this is made more clear later:

>    When an endpoint that supports the FORWARD TSN chunk receives an INIT
>    that does not contain the Forward-TSN-Supported Parameter, that
>    endpoint:
>
>    o  MAY include the Forward-TSN-Supported parameter in the INIT-ACK,
>
>    o  SHOULD record the fact that the peer does not support the FORWARD
>      TSN chunk,
>
>    o  MUST NOT send a FORWARD TSN chunk at any time during the
>      associations life,
>
>    o  SHOULD inform the upper layer, if the upper layer has requested
>      such notification.

But these rules seem odd (to me). Why would the ACK include the
Forward-TSN-supported if the INIT doesn't? Seems completely useless.
Second should is rather obvious. You need to record whether the other
side implements (if you do), so you know if you can send or not.

then...

> 7. Security Considerations
>
>    This document does not introduce any new security concerns to SCTP
>    other than the ones already documented in RFC2960 [3]. In particular
>    this document shares the same security issues as unordered data
>    within RFC2960 [3] identified by RFC3436 [5]. An application using
>    the PR-SCTP extension should not use transport layer security;
>    further details can be found in RFC3436 [5].

This option provides new way for a MITM (or other intruder) to
interfere with the packet flow. But this is the case in general
already, so the question is whether this makes things any worse than
things alread are.

I wonder about the following. If the sender SCTP indicates the
capability of supporting the new mode, and the receiver acknowledges
that it also supports the mode, _but_ neither the sender nor receiving
application (or maybe not both of them) requested the service, could
an intruder introduce messages that cause individual chunks to be
"abandoned" without either side noticing? This may not be a big attack
to worry about (compared to other types of attack), but it may be
preventable if:

  - it is only permitted if both SCTP endpoints negotiated the option

  - SCTP  only negotiates usage if the upper layer protocol has
    requested it do so.

Suggestion: make the following rules clear:

- INIT includes Forward-TSN-Supported only if application indicates
  it wants this feature
 
- INIT-ACK only includes Forward-TSN-Supported if it supports it AND
  upper layer application has requested its use, and in response to
  an INIT indicating support for the option.

>        Stream Sequence-N: 16 bit u_int
>
>          This field holds the sequence number associated with the stream
>          that was skipped. The stream sequence field holds the largest stream
>          sequence number in this stream being skipped.  The receiver of
>          the FWD-TSN's can use the Stream-N and Stream Sequence-N fields
>          to enable delivery of any stranded TSN's that remain on the stream
>          re-ordering queues. This field MUST NOT report TSN's corresponding
>          to DATA chunk that are marked as unordered. For ordered DATA
>          chunks this field MUST be filled in.

There seems to be an interesting edge case here. Suppose a data chunk
has been received, but not handed upwards, due to a missing sequence
number. But then a Forward-TSN arrives basically saying "we don't care
about this sequence number anymore". Should the receiver discard it?
(that would be correct behavior semantically -- the sender has
concluded it is no longer timely). Or it should it forward it up the
stack, since it has the data already. This document doesn't seem to
say what to do in this case. Indeed, the wording above might be
confusing as it talks about "enable delivery of stranded TSN".  I
assume this is NOT about the case I just described (but is that clear)
and is really trying to say that if the Forward-TSN moves the sequence
number to X, and chunk X has already been received, it can now be
handed upwards and the received sequence numbers adjusted
accordingly. It might be good to clarify these two points.


>      C3) If, after step C1 and C2, the "Advanced.Peer.Ack.Point" is
>          greater than the Cumulative TSN ACK carried in the received
>          SACK, the data sender MUST send the data receiver a FORWARD TSN
>          chunk containing the latest value of the
>          "Advanced.Peer.Ack.Point".
>
>          IMPLEMENTATION NOTE: It is an implemenation decision as to
>          which destination address is to be sent to, the only
>          restriction being that the address MUST be one that is
>          CONFIRMED.

Are there any corner cases here like if the a chunk is abandoned less
than one RTT after it was first queued? I.e., the above MUST might
lead to situations where you get several incoming SACKs that cause a
corresponding resent of the Forward-TSN chunk.

Actually, the somewhate MUST is contradicted later by MAYs, i.e.:

      A sender MAY even choose to delay the sending of the FORWARD TSN
      in the hope of bundling it with an outbound DATA chunk.

Maybe tweak the earlier wording with a pointer to the later text?

>    The new OPTIONAL parameter "forward tsn supported" is a boolean flag:
>
>    (0) false [default] indicates that FORWARD TSN is not supported by
>      the peer.
>
>    (1) true indicates that FORWARD TSN is supported by the peer.

Maybe a minor point, but shouldn't the semantics of this be "supported
by both sender and receiver"? That's what you care about, and if the
sender doesn't support this, it matters not if the peer does. Or, is
there some other way the sender determines whether the sending SCTP
supports this and  it is only allowed to request the feature if it
already knows its supported on the sender?

>    TR4) Before transmitting or retransmitting a message for which a TSN
>      is already assigned, the SCTP sender MUST evaluate the lifetime of
>      the message.  If the lifetime of the message is expired, the SCTP
>      sender MUST "abandon" the message, as per the rules specified in
>      Section 3.5 marking that TSN as eligible for forward TSN. Note
>      that this meets the requirement G1 defined in Section 4.3

I think TR4 should be split into two cases. In the case that a message
has not been transmitted yet, there is no need for "abandoning" the
messages as per this document. It can be handled using the previous
technique. This is important, because it means no messages go out on
the wire. Its only if the message has been transmitted once that one
needs to abandon...

Also, I think there should be some text/rules that say how to handle
the case of transmitting a DATA chunk (for the first time) it if is
clear that it would be scheduled for abandonment _before_ the RTT will
expire. I.e., its guaranteed to be "old" before the ACK comes
back. Naive implementations that don't think about this might do dumb
things. I don't think much text is needed, but it woudl be good to
notify implementors of the issue and what they should do about it.


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.
2003-12-18
03 Thomas Narten [Ballot Position Update] New position, Discuss, has been recorded for  by Thomas Narten
2003-12-18
03 Amy Vezza Removed from agenda for telechat - 2003-12-18 by Amy Vezza
2003-12-18
03 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2003-12-18
03 Amy Vezza [Ballot Position Update] Position for Ted Hardie has been changed to Discuss from No Objection by Amy Vezza
2003-12-18
03 Amy Vezza [Ballot Position Update] New position, No Objection, has been recorded for  by Amy Vezza
2003-12-18
03 Steven Bellovin [Ballot Position Update] Position for Steve Bellovin has been changed to No Objection from Undefined by Steve Bellovin
2003-12-18
03 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for  by Bill Fenner
2003-12-18
03 Bert Wijnen
[Ballot comment]
From OPS Directorate (Pekka)

Nits
Abstract
  This memo describes an extension to the Stream Control Transmission
  Protocol (SCTP) RFC2960 [3] that …
[Ballot comment]
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./
2003-12-18
03 Bert Wijnen [Ballot Position Update] New position, No Objection, has been recorded for  by Bert Wijnen
2003-12-18
03 Alex Zinin [Ballot Position Update] New position, No Objection, has been recorded for  by Alex Zinin
2003-12-17
03 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded for  by Margaret Wasserman
2003-12-17
03 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for  by Russ Housley
2003-12-16
03 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Undefined by Ted Hardie
2003-12-16
03 Ted Hardie
[Ballot comment]
Section 3.6 says:

  Whenever a DATA chunk arrives with the 'U' bit set to '0' (indicating
  ordered delivery) and is out …
[Ballot comment]
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.
2003-12-16
03 Ted Hardie
[Ballot comment]
Section 3.6 says:

  Whenever a DATA chunk arrives with the 'U' bit set to '0' (indicating
  ordered delivery) and is out …
[Ballot comment]
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?
2003-12-16
03 Ted Hardie [Ballot Position Update] New position, Undefined, has been recorded for  by Ted Hardie
2003-12-16
03 Allison Mankin [Ballot Position Update] New position, Yes, has been recorded for  by Allison Mankin
2003-12-16
03 Jon Peterson State Changes to IESG Evaluation from Waiting for Writeup by Jon Peterson
2003-12-16
03 Steven Bellovin
[Ballot comment]
I didn't see any discussion about what a receiver should do if an abandoned TSN arrives after the abandonment message.  Is this a …
[Ballot comment]
I didn't see any discussion about what a receiver should do if an abandoned TSN arrives after the abandonment message.  Is this a problem?
2003-12-16
03 Steven Bellovin [Ballot Position Update] New position, Undefined, has been recorded for  by Steve Bellovin
2003-12-12
03 Ned Freed [Ballot Position Update] New position, No Objection, has been recorded for  by Ned Freed
2003-12-11
03 Jon Peterson Placed on agenda for telechat - 2003-12-18 by Jon Peterson
2003-12-11
03 Jon Peterson [Ballot Position Update] New position, Yes, has been recorded for Jon Peterson
2003-12-11
03 Jon Peterson Ballot has been issued by Jon Peterson
2003-12-11
03 Jon Peterson Created "Approve" ballot
2003-12-02
03 (System) State has been changed to Waiting for Writeup from In Last Call by system
2003-12-01
02 (System) New version available: draft-ietf-tsvwg-prsctp-02.txt
2003-11-18
03 Amy Vezza Last call sent
2003-11-18
03 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2003-11-18
03 Jon Peterson Last Call was requested by Jon Peterson
2003-11-18
03 Jon Peterson State Changes to Last Call Requested from AD Evaluation by Jon Peterson
2003-11-18
03 (System) Ballot writeup text was added
2003-11-18
03 (System) Last call text was added
2003-11-18
03 (System) Ballot approval text was added
2003-10-06
03 Jon Peterson State Changes to AD Evaluation from Publication Requested by Jon Peterson
2003-09-12
03 Jon Peterson Intended Status has been changed to Proposed Standard from None
2003-09-12
03 Jon Peterson Draft Added by Jon Peterson
2003-08-22
01 (System) New version available: draft-ietf-tsvwg-prsctp-01.txt
2003-06-19
00 (System) New version available: draft-ietf-tsvwg-prsctp-00.txt