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 |