Stream Control Transmission Protocol
draft-ietf-tsvwg-rfc4960-bis-19
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2022-06-04
|
19 | (System) | RFC Editor state changed to AUTH48-DONE from TI |
2022-05-31
|
19 | (System) | RFC Editor state changed to TI from AUTH48-DONE |
2022-05-27
|
19 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2022-04-05
|
19 | (System) | RFC Editor state changed to AUTH48 |
2022-03-15
|
19 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2022-02-08
|
19 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2022-02-08
|
19 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2022-02-08
|
19 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2022-02-08
|
19 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2022-02-08
|
19 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2022-02-07
|
19 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2022-02-07
|
19 | (System) | RFC Editor state changed to EDIT |
2022-02-07
|
19 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2022-02-07
|
19 | (System) | Announcement was received by RFC Editor |
2022-02-07
|
19 | (System) | IANA Action state changed to In Progress |
2022-02-07
|
19 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2022-02-07
|
19 | Cindy Morgan | IESG has approved the document |
2022-02-07
|
19 | Cindy Morgan | Closed "Approve" ballot |
2022-02-07
|
19 | Cindy Morgan | Ballot approval text was generated |
2022-02-07
|
19 | (System) | Removed all action holders (IESG state changed) |
2022-02-07
|
19 | Martin Duke | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2022-02-06
|
19 | Benjamin Kaduk | [Ballot comment] Many thanks for the extensive and very thoughtful discussion in response to my previous ballot comments; I'm happy to say that we reached … [Ballot comment] Many thanks for the extensive and very thoughtful discussion in response to my previous ballot comments; I'm happy to say that we reached resolution on all of them (for some of them, educating me on my misunderstandings). |
2022-02-06
|
19 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2022-02-05
|
19 | (System) | Changed action holders to Martin Duke (IESG state changed) |
2022-02-05
|
19 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2022-02-05
|
19 | Michael Tüxen | New version available: draft-ietf-tsvwg-rfc4960-bis-19.txt |
2022-02-05
|
19 | (System) | New version accepted (logged-in submitter: Michael Tüxen) |
2022-02-05
|
19 | Michael Tüxen | Uploaded new revision |
2022-01-25
|
18 | (System) | Changed action holders to Randall Stewart, Michael Tüxen, Martin Duke, Karen Nielsen (IESG state changed) |
2022-01-25
|
18 | Martin Duke | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup |
2022-01-16
|
18 | (System) | Changed action holders to Martin Duke (IESG state changed) |
2022-01-16
|
18 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2022-01-16
|
18 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2022-01-16
|
18 | Michael Tüxen | New version available: draft-ietf-tsvwg-rfc4960-bis-18.txt |
2022-01-16
|
18 | (System) | New version accepted (logged-in submitter: Michael Tüxen) |
2022-01-16
|
18 | Michael Tüxen | Uploaded new revision |
2021-12-16
|
17 | (System) | Changed action holders to Randall Stewart, Michael Tüxen, Martin Duke, Karen Nielsen (IESG state changed) |
2021-12-16
|
17 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2021-12-16
|
17 | Benjamin Kaduk | [Ballot discuss] My apologies for placing a Discuss so close to the telechat. I believe that both of these topics are comparatively minor and should … [Ballot discuss] My apologies for placing a Discuss so close to the telechat. I believe that both of these topics are comparatively minor and should be easy to resolve, but that it's important for the document to have a clear answer for them. I ask this with nospecific answer in mind that I need to hear -- per my comments on §5.1.3, what are the actual requirements on the (cryptographic) protection of the State Cookie? I feel like I got different signals from different parts of the document, and it would be good to have consistent messaging throughout. Section 15.5 establishes a registry for payload protocol identifiers, but I am not sure how this registry is supposed to be able to effectively avoid collisions when we do not specify the endianness in which the value is represented on the wire (per §3.3.1). |
2021-12-16
|
17 | Benjamin Kaduk | [Ballot comment] Peeking in the github repo for purposes of preparing an editorial PR, I see that the original RFC 4960 was prepared in nroff … [Ballot comment] Peeking in the github repo for purposes of preparing an editorial PR, I see that the original RFC 4960 was prepared in nroff -- my thanks to the authors for the thankless work of converting it to XML! I'm also glad to see the robustness changes made to the procedures for handling INIT (and INIT ACK) chunks with invalid parameters. I am also sympathetic to Alvaro's point about obsoleting additional documents. I only got a chance to review the diff from RFC 4960 and a small selection of portions of this document, so this review is not as comprehensive as I would typically perform. That said, I trust that the document has received sufficient review and therefore am comfortable reballoting No Objection once my discuss points are resolved. I put some editorial suggestions in a PR on github: https://github.com/sctplab/rfc4960bis/pull/79 Abstract I see that Warren already remarked about the length of the Abstract. I have in my bookmarks https://www.rfc-editor.org/policy.html#policy.abstract that indicates "[a]n Abstract of more than 20 lines is generally not acceptable." Section 3.3.4 Cumulative TSN Ack: 32 bits (unsigned integer) The largest TSN, such that all TSNs smaller than or equal to it have been received and the next one has not been received. (nit) The "and the next one has not been received" is implied by "largest ... such that", since if the next one had been received, this one would not be the largest such that the condition holds. (This phrasing also seemse to appear in §3.3.8.) I didn't remove this in my editorial PR because it is plausible that the redundancy is desired for emphasis. Section 5.1.3 When would it be permissible to not include a MAC on the State Cookie data? It seems like we refer to it as essentially mandatory from other parts of the spec, so I was surprised to see it only as a "SHOULD" here. E.g., in §5.1.5 the first step in processing COOKIE ECHO is "compute a MAC [and compare it to the one in the cookie]" -- there's no point in doing that if there's no MAC in the cookie. Similarly, in §14.1 "Parameters Necessary for the SCTP Instance" we list a secret key for computing the MAC. Since the State Cookie is not encrypted, it MUST NOT contain information which is not being envisioned to be shared. What prevents the state cookie from being encrypted (other than performance concerns)? Perhaps we just need to require that *if* the state cookie is not encrypted, it doesn't contain such information. Section 6.2 An SCTP receiver MUST NOT generate more than one SACK chunk for every incoming packet, other than to update the offered window as the receiving application consumes new data. When the window opens up, an SCTP receiver SHOULD send additional SACK chunks to update the window even if no new data is received. The receiver MUST avoid sending a large number of window updates -- in particular, large bursts of them. [...] "a large number" feels somewhat subjective, such that the power of the "MUST"-level requirement is weakened. If an endpoint receives a DATA chunk with no user data (i.e., the Length field is set to 16), it MUST send an ABORT chunk with a "No User Data" error cause. An endpoint SHOULD NOT send a DATA chunk with no user data part. This avoids the need to be able to return a zero-length user message in the API, especially in the socket API as specified in [RFC6458] for details. This is just a COMMENT since the behavior was present in 4960, but why allow sending an empty data chunk when the receiver is required to abort because of it? This seems like the reverse of the Postel principle. Section 6.5 Every DATA chunk MUST carry a valid stream identifier. If an endpoint receives a DATA chunk with an invalid stream identifier, it SHOULD acknowledge the reception of the DATA chunk following the normal procedure, immediately send an ERROR chunk with cause set to "Invalid Stream Identifier" (see Section 3.3.10), and discard the DATA chunk. [...] What other behaviors are permitted (i.e., why is this SHOULD vs MUST)? The Stream Sequence Number in all the outgoing streams MUST start from 0 when the association is established. [...] If we were starting from scratch this would probably be undesirable (a la draft-gont-numeric-ids-sec-considerations), but I guess it's not really changeable now, and we have to rely on the random initial TSN and verifiers to prevent off-path guessing. Section 11.2.5 Looking at the diff from RFC 4960, it seems that we no longer claim that there is a "data retrieval id" passed with the communication-lost notification. I don't have a great sense for whether this makes sense, e.g., due to an expectation that SEND-FAILURE events will be generated separately for all affected messages. Section 12 My apologies if I failed to find some relevant content in my somewhat-piecemeal review, but I note that we require each HEARTBEAT chunk to receive a corresponding HEARTBEAT ACK, so that (according to the protocol rules) an endpoint can force the peer to do work. Since the heartbeat is expected to only occur once every RTO or so (or less often), should we allow an endpoint to abort the association on receipt of too many heartbeats? It also looks like it's allowed for a sender to leave gaps in the TSN space when sending (non-fragmented) DATA chunks. This is also the case for QUIC (for the analogous numer space), and in QUIC's security considerations there is a note that a sender who suspects the peer of misbehaving (i.e., sending false/speculative ACKs) can deliberately leave such a gap and abort the association if the non-existent TSN is ACKed. Do we want to make such a statement here as well? Section 12.2.3 Whenever ESP is in use, application-level encryption is not generally required. I suggest removing this statement; we now have plenty of examples where double-encryption is actually the right solution, and advances in computing power have removed many reasons to desire avoiding it. Section 12.2.4.1 The design of SCTP is resistant to flooding attacks, particularly in its use of a four-way startup handshake, its use of a cookie to defer commitment of resources at the responding SCTP node until the handshake is completed, and its use of a Verification Tag to prevent insertion of extraneous packets into the flow of an established association. I suggest mentioning here that using distinct initial TSN and initiate tag values improves robustness against such attacks, by making attackers guess 32 more bits of values. (§3.2.2 and 3.2.3 do allow for the values to be the same, with concomitant reduced protection.) The IP Authentication Header and Encapsulating Security Payload might be useful in reducing the risk of certain kinds of denial-of-service attacks. Current IPSECME WG guidance is to prefer ESP with NULL encryption over AH, so I'd recommend not mentioning AH here. Section 12.4 INIT ACK chunk will be larger than the original INIT chunk. An SCTP implementation SHOULD attempt to make the INIT ACK chunk as small as possible to reduce the possibility of byte amplification attacks. The emerging consensus in QUIC and (D)TLS seems to be to limit the amplification factor to at most three times the received data; do we want to mention that heuristic here? Section 15.6 SCTP services can use contact port numbers to provide service to unknown callers, as in TCP and UDP. IANA is requested to open the existing "Service Name and Transport Protocol Port Number Registry" for SCTP using the following rules, which we intend to mesh well with existing port-number registration procedures. [...] I don't really see anything following that looks like rules for IANA to follow. Is that phrase stale text from 4960? (Deferring the actual procedures to RFC 6335 seems like the right approach.) Section 18 Some of these references probably don't need to be classified as normative. e.g., RFC 3873 is the MIB for SCTP, but we don't require its implementation, and RFC 4301 is only referenced for "operators might consult [RFC4301]". Appendix A I'd consider updating the note about the modifications made to the sample code; noteworthy changes appear to include the use of fixed-width types and some general cleanup for modern C best practices. Also, it might be worth checking for undefined behavior -- "1 << (31 - i)" will be UB for i==1 on systems with 32-bit int, since 2**31 is not representable in (signed) int, which is the default type in which the expression will be evaluated, even if the result is going to be assigned to an unsigned type. |
2021-12-16
|
17 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2021-12-16
|
17 | Francesca Palombini | [Ballot comment] Thank you for the work on this document. Many thanks to Eliot Lear for his thoughtful review: https://mailarchive.ietf.org/arch/msg/art/j0zknGwfrVc4rIzEqD3tE2kmFgY/ , and thanks to the … [Ballot comment] Thank you for the work on this document. Many thanks to Eliot Lear for his thoughtful review: https://mailarchive.ietf.org/arch/msg/art/j0zknGwfrVc4rIzEqD3tE2kmFgY/ , and thanks to the authors for addressing his comments, as well as incorporating changes that improved the text. Francesca |
2021-12-16
|
17 | Francesca Palombini | [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini |
2021-12-16
|
17 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. I am copying Rob Wilton's text as it also applies to my review: … [Ballot comment] Thank you for the work put into this document. I am copying Rob Wilton's text as it also applies to my review: "Given my lack of familiarity with STCP, I have only quickly reviewed the diffs before this document and the base RFC, and do not have any significant comments that will improve this document." Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Gorry Fairhurst for the shepherd's write-up including the section about the WG consensus. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 10 -- I wonder what is the purpose of this section dedicated to ICMP handling, e.g., ICMP1-5 are pretty obvious. It is of course not harmful to keep this section but perhaps limit it to the important ones like ICMP6 and the rest ? ICMP7: please s/v4/IPv4/ and s/v6/IPv6/ (also applicable in other parts). I would also prefer s/an implementation MAY process/an implementation SHOULD process/ -- Section 12.2.4.1. -- Suggest to use "ESP" wording as in 12.2.3 About "IP Authentication Header", I am unsure whether it is still commonly used and adding a reference to RFC 4302 is probably required. -- Section 7.2.1 -- Just curious about why the "cwd" is computed differently for IPv4 and IPv6 (I do not understand the 60 bytes difference) |
2021-12-16
|
17 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2021-12-16
|
17 | Éric Vyncke | Request closed, assignment withdrawn: Ted Lemon Telechat INTDIR review |
2021-12-16
|
17 | Éric Vyncke | Closed request for Telechat review by INTDIR with state 'Withdrawn': The document is on the IESG telechat today. No need anymore for a review (still … Closed request for Telechat review by INTDIR with state 'Withdrawn': The document is on the IESG telechat today. No need anymore for a review (still welcome by the authors probably). |
2021-12-16
|
17 | Zaheduzzaman Sarker | [Ballot comment] Thanks to the authors and contributors for making the 4960-bis happen. This surely shows the dedication to this work. SCTP is important part … [Ballot comment] Thanks to the authors and contributors for making the 4960-bis happen. This surely shows the dedication to this work. SCTP is important part of Radio Access Network (RAN) deployment. I found the changes between -15 and -17 are very good. I don't think I have additional comments or concerns for this specifications. On the question of obsoleting RFC 8540 brought up by my IESG colleagues, I know RFC 8540's role for 4960-bis and this bis refers (informative) to RFC 8540 for further details. I don't think obsoleting RFC 8540 will change the reference for details relation form 4960-bis. Then the question is -- is there anything in the RFC 8540 that has not been included in this 4960-bis and that need to leave of it's own? If the answer is NO then we might just obsolete RFC 8540. |
2021-12-16
|
17 | Zaheduzzaman Sarker | [Ballot Position Update] New position, Yes, has been recorded for Zaheduzzaman Sarker |
2021-12-15
|
17 | Murray Kucherawy | [Ballot comment] I also relied largely on the diff to RFC 4960 for my review, and I only found a couple of things to mention. … [Ballot comment] I also relied largely on the diff to RFC 4960 for my review, and I only found a couple of things to mention. First, I'm also curious about the Internet Standard question raised by other ADs. Section 15.4, which is largely copied from RFC 4960's Section 14.3, defines a Specification Required registry. RFC 8126 says that advice for the designated expert reviewing these should be provided. I realize such was missing from the original; should we take this opportunity to add some? Section 15 as a whole is really big; the text in 15 (i.e., all the stuff before 15.1) could probably benefit from being broken into subsections. |
2021-12-15
|
17 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2021-12-15
|
17 | Erik Kline | [Ballot comment] [general; comment] * I suspect that my notion of {src,dst} transport address tracking doesn't align with the model under which this was … [Ballot comment] [general; comment] * I suspect that my notion of {src,dst} transport address tracking doesn't align with the model under which this was developed. There are several places where parameters associated with a given destination address might be tracked on a {src,dst} basis, at least for implementations for which the accompanying complexity was deemed justified. Some observations are made in this context; I don't expect they need to be considered at this (bis) point in time. [S2.7; nit] * s/Describe ... more precise/Describe ... more precisely/ [S5.2; question] * In light of Path Verification discussion in 5.4 is one of the reasons that a (duplicate) COOKIE-ECHO chunk might arrive a consequence of path probing during connection setup? [S5.4, S7.3, S8.3; question] * Is the assumption here that there will be only be one source address selected for each proposed destination address? I would have thought that if the INIT and INIT-ACK each had multiple IP addresses that the probed paths (and thus paths along which PMTU discovery would be performed) could in fact be the union of the Cartesian cross product of all {INIT} x {INIT-ACK} addresses of matching address family. [S6; nit] * At first I thought "out of the blue" might be replaced with something less idiomatic for non-native English readers, but I see that S8.4 goes so far as to craft the OOTB acronym. Perhaps add this phrase and a one-sentence summary (and maybe a link to S8.4) to the list of key terms in Section 2.3. [S6.5; question] * Does this mean that the first unordered user message within a stream uses a Stream Sequence Number of previous+1 and that all subsequent unordered messages on that stream MUST use the same sequence number (of that first unordered message)? (The fact that unordered messages don't cause an increase in sequence numbers struck me as a bit odd/unnecessary.) [S8.2; nit] * s/user ought avoid/user ought to avoid/ [S11.1.5; comment] * It may be too late, but it seems like an optional [,source transport address] might be part of the API for platforms that might want to allow sending from more than one validated/active source address. [S11.1.7; comment] * It may be too late, but should there be an optional local transport address to indicate at which local address a message was sent? I get that packets might arrive at multiple local addresses, but given that (I think) they can be sent from multiple remote addresses and there is a parameter to return the sender's address, I just thought... [S11.1.9; comment] * It may be too late, but should there be an optional source transport address parameter as well? [S11.1.10; comment] * It may be too late, but should there be an optional source transport address parameter as well? |
2021-12-15
|
17 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2021-12-15
|
17 | John Scudder | [Ballot comment] Thanks for your work on this. I noticed in the shepherd write up: “SCTP is implemented in endpoints either in the operating system … [Ballot comment] Thanks for your work on this. I noticed in the shepherd write up: “SCTP is implemented in endpoints either in the operating system or a user stack. Running code for SCTP exists in several TCP/IP stacks. All main STCP implementations are expected to comply with 4960.bis. **The document is expected to fulfill the requirements of an "Internet Standard"** according to RFC 2026 and RFC 7127.” (emphasis added) I wonder why that isn't the intended status, then? |
2021-12-15
|
17 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
2021-12-15
|
17 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2021-12-15
|
17 | Warren Kumari | [Ballot comment] Thank you all of the work on this, and to Linda Dunbar for the OpsDir review. I fully agree with Alvaro that this … [Ballot comment] Thank you all of the work on this, and to Linda Dunbar for the OpsDir review. I fully agree with Alvaro that this document should obsolete RFC 8540, and that it should be updated to say so. In addition, I had started writing up a slightly grumpy ballot about how long the Abstract was, but then realized that this is almost as long in the original :-) Thanks again, W |
2021-12-15
|
17 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2021-12-15
|
17 | Alvaro Retana | [Ballot comment] [This point doesn't reach the level of a DISCUSS, but I believe it is important and that it must be addressed before publication.] … [Ballot comment] [This point doesn't reach the level of a DISCUSS, but I believe it is important and that it must be addressed before publication.] This document should Obsolete rfc8540, which was used to provide "a history of the changes that will be compiled into a bis document for [RFC4960]." With the publication of this document, it will have reached the end of its useful life. Note that rfc4460 was not declared Obsolete by rfc4960. So this document should take care of that too. |
2021-12-15
|
17 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2021-12-15
|
17 | Robert Wilton | [Ballot comment] Thanks for pulling these updates together - I think that it will make a helpful future reference. Given my lack of familiarity with … [Ballot comment] Thanks for pulling these updates together - I think that it will make a helpful future reference. Given my lack of familiarity with STCP, I have only quickly reviewed the diffs before this document and the base RFC, and do not have any significant comments that will improve this document. I was slightly surprised to see that this wasn't going for Internet Standard rather than Proposed Standard, but I presume that this was considered and there was a good reason not to do so. Regards, Rob |
2021-12-15
|
17 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2021-12-14
|
17 | Roman Danyliw | [Ballot comment] Thank you to David Mandelberg for the SECDIR review. ** Section 2.5.3 Once a user message has been fragmented, this fragmentation cannot … [Ballot comment] Thank you to David Mandelberg for the SECDIR review. ** Section 2.5.3 Once a user message has been fragmented, this fragmentation cannot be changed anymore. This new text appears to have been added for clarity, but I don’t follow the intent. ** Section 3.3.5 When a HEARTBEAT chunk is being used for path verification purposes, it MUST hold a random nonce of length 64-bit or longer ([RFC4086] provides some information on randomness guidelines). As a carryover from RFC4960, the text makes clear that 64-bits is a minimum. Is there any guidance on the trade-space of why and when a larger nonce should be used? ** Section 5.1.3 Choosing a high performance MAC algorithm increases the resistance against cookie flooding attacks. A MAC with acceptable security properties SHOULD be used. Is “acceptable security properties” a use case specific decision and therefore out of scope? Taking the position of an implementer, I’m not sure how to act on this normative “SHOULD”. ** Section 12.2.4 or 12.3. These sections appear to be establishing the expectations for SCTP endpoints and middle-boxes. Section 12.2.* discusses denial of service attacks and associated mitigations via logging and statement management by the end-points. Would it be worth mentioning that middle-boxes can also play a role in filtering and rate limiting if needed? |
2021-12-14
|
17 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2021-12-03
|
17 | Carlos Jesús Bernardos | Request for Telechat review by INTDIR is assigned to Ted Lemon |
2021-12-03
|
17 | Carlos Jesús Bernardos | Request for Telechat review by INTDIR is assigned to Ted Lemon |
2021-12-01
|
17 | Éric Vyncke | Requested Telechat review by INTDIR |
2021-11-10
|
17 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2021-11-08
|
17 | Michael Tüxen | New version available: draft-ietf-tsvwg-rfc4960-bis-17.txt |
2021-11-08
|
17 | (System) | New version accepted (logged-in submitter: Michael Tüxen) |
2021-11-08
|
17 | Michael Tüxen | Uploaded new revision |
2021-11-05
|
16 | David Mandelberg | Request for Telechat review by SECDIR Completed: Has Nits. Reviewer: David Mandelberg. Sent review to list. |
2021-11-05
|
16 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to David Mandelberg |
2021-11-05
|
16 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to David Mandelberg |
2021-10-29
|
16 | Cindy Morgan | Placed on agenda for telechat - 2021-12-16 |
2021-10-29
|
16 | Martin Duke | Ballot has been issued |
2021-10-29
|
16 | Martin Duke | [Ballot Position Update] New position, Yes, has been recorded for Martin Duke |
2021-10-29
|
16 | Martin Duke | Created "Approve" ballot |
2021-10-29
|
16 | Martin Duke | IESG state changed to IESG Evaluation from Waiting for Writeup::AD Followup |
2021-10-29
|
16 | Martin Duke | Ballot writeup was changed |
2021-10-26
|
16 | Martin Duke | Awaiting designated experts; will then complete ballot and submit. |
2021-10-26
|
16 | Martin Duke | Ballot writeup was changed |
2021-10-25
|
16 | (System) | Changed action holders to Martin Duke (IESG state changed) |
2021-10-25
|
16 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-10-25
|
16 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2021-10-25
|
16 | Michael Tüxen | New version available: draft-ietf-tsvwg-rfc4960-bis-16.txt |
2021-10-25
|
16 | (System) | New version approved |
2021-10-25
|
16 | (System) | Request for posting confirmation emailed to previous authors: Karen Nielsen , Michael Tuexen , Randall Stewart |
2021-10-25
|
16 | Michael Tüxen | Uploaded new revision |
2021-10-18
|
15 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: David Mandelberg. |
2021-10-14
|
15 | Ines Robles | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Ines Robles. Sent review to list. |
2021-10-14
|
15 | (System) | Changed action holders to Randall Stewart, Michael Tüxen, Martin Duke, Karen Nielsen (IESG state changed) |
2021-10-14
|
15 | Martin Duke | IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup |
2021-10-14
|
15 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2021-10-13
|
15 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2021-10-13
|
15 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-tsvwg-rfc4960-bis-15. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-tsvwg-rfc4960-bis-15. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there are eleven actions which we must complete. First, in the Chunk Types registry on the Stream Control Transmission Protocol (SCTP) Parameters registry page located at: https://www.iana.org/assignments/sctp-parameters/ the reference to [RFC4960] and [RFC6096] will be replaced by a reference to [ RFC-to-be ]. In the Notes section the reference to Section 3.2 of [RFC6096] by a reference to Section 15.2 of [ RFC-to-be ]. The reference to [RFC4960] will be replaced by a reference to [ RFC-to-be ] for the following sixteen chunk types in the registry: Payload Data (DATA) Initiation (INIT) Initiation Acknowledgement (INIT ACK) Selective Acknowledgement (SACK) Heartbeat Request (HEARTBEAT) Heartbeat Acknowledgement (HEARTBEAT ACK) Abort (ABORT) Shutdown (SHUTDOWN) Shutdown Acknowledgement (SHUTDOWN ACK) Operation Error (ERROR) State Cookie (COOKIE ECHO) Cookie Acknowledgement (COOKIE ACK) Reserved for Explicit Congestion Notification Echo (ECNE) Reserved for Congestion Window Reduced (CWR) Shutdown Complete (SHUTDOWN COMPLETE) Reserved for IETF-defined Chunk Extensions Second, in the Chunk Parameter Types Registry also on the Stream Control Transmission Protocol (SCTP) Parameters registry page located at: https://www.iana.org/assignments/sctp-parameters/ the reference to [RFC4960] will be replaced by a reference to [ RFC-to-be ]. The reference to [RFC4960] will be replaced by a reference to [ RFC-to-be ] for the following eight chunk parameter types in the registry: Heartbeat Info IPv4 Address IPv6 Address State Cookie Unrecognized Parameters Cookie Preservative Host Name Address Supported Address Types A reference will be added to the following chunk parameter type: Reserved for ECN Capable (0x8000) Third, in the Chunk Flags Registry also on the Stream Control Transmission Protocol (SCTP) Parameters registry page located at: https://www.iana.org/assignments/sctp-parameters/ the reference to [RFC6096] will be replaced by a reference to [ RFC-to-be ]. The reference to [RFC4960] will be replaced by a reference to [ RFC-to-be ] for the following three DATA chunk flags in the registry: E bit B bit U bit The reference to [RFC4960] will be replaced by a reference to [ RFC-to-be ] for the following ABORT chunk flags in the registry: T bit The reference to [RFC4960] will be replaced by a reference to [ RFC-to-be ] for the following SHUTDOWN COMPLETE chunk flags in the registry: T bit Fourth, in the Error Cause Codes Registry also on the Stream Control Transmission Protocol (SCTP) Parameters registry page located at: https://www.iana.org/assignments/sctp-parameters/ the reference to [RFC6096] will be replaced by a reference to [ RFC-to-be ]. The reference to [RFC4960] will be replaced by a reference to [ RFC-to-be ] for the following eleven error cause codes in the registry: Invalid Stream Identifier Missing Mandatory Parameter Stale Cookie Error Out of Resource Unresolvable Address Unrecognized Chunk Type Invalid Mandatory Parameter Unrecognized Parameters No User Data Cookie Received While Shutting Down Restart of an Association with New Addresses The reference to [RFC4460] will be replaced by a reference to [ RFC-to-be ] for the following two error cause codes in the registry: User Initiated Abort Protocol Violation Fifth, in the SCTP Payload Protocol Identifiers Registry also on the Stream Control Transmission Protocol (SCTP) Parameters registry page located at: https://www.iana.org/assignments/sctp-parameters/ the reference to [RFC6096] will be replaced by a reference to [ RFC-to-be ]. The reference to [RFC4960] will be replaced by a reference to [ RFC-to-be ] for the following SCTP payload protocol identifier in the registry: Reserved by SCTP Sixth, in the Service Name and Transport Protocol Port Number Registry located at: https://www.iana.org/assignments/service-names-port-numbers/ The reference to [RFC4960] will be replaced by a reference to [ RFC-to-be ] for the following seven SCTP port numbers in the registry: 9 (discard) 20 (ftp-data) 21 (ftp) 22 (ssh) 80 (http) 179 (bgp) 443 (https) Seventh, in the HTTP Digest Algorithm Values registry located at: https://www.iana.org/assignments/http-dig-alg/ the reference to Appendix B of [RFC4960] in the registration for digest algorithm CRC32c will be changed to Appendix A of [ RFC-to-be ]. Eighth, in the ONC RPC Netids (Standards Action) registry on the ONC RPC Network Identifiers (netids) registry page located at: https://www.iana.org/assignments/rpc-netids/ the reference to [RFC4960] by a reference to [ RFC-to-be ] for the following two netids: sctp sctp6 Ninth, in the IPFIX Information Elements registry on the IP Flow Information Export (IPFIX) Entities registry page located at: https://www.iana.org/assignments/ipfix/ the reference to [RFC4960] by a reference to [ RFC-to-be ] for the following six IPFIX Information Elements: sourceTransportPort destinationTransportPort collectorTransportPort exporterTransportPort postNAPTSourceTransportPort postNAPTDestinationTransportPort Tenth, in sections 15.1, 15.2, 15.3, 15.4 and 15.5 IANA understands that the authors are documenting the requirements for future registrations in five existing registries located on the Stream Control Transmission Protocol (SCTP) Parameters registry page located at: https://www.iana.org/assignments/sctp-parameters/ SCTP chunk types SCTP chunk flags SCTP chunk parameter types SCTP error cause codes SCTP payload protocol identifiers IANA understands that no changes are being made to the existing registries based on the five sections identified above (15.1, 15.2, 15.3, 15.4 and 15.5). Eleventh, section 15.6 provides guidance regarding expert review for SCTP port requests in the Service Name and Transport Protocol Port Number Registry located at: https://www.iana.org/assignments/service-names-port-numbers/ IANA understands that no changes are being made to the existing registries based on this section (15.6). The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Lead IANA Services Specialist |
2021-10-12
|
15 | Linda Dunbar | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Linda Dunbar. Sent review to list. |
2021-10-08
|
15 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to David Mandelberg |
2021-10-08
|
15 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to David Mandelberg |
2021-10-06
|
15 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Linda Dunbar |
2021-10-06
|
15 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Linda Dunbar |
2021-10-04
|
15 | Eliot Lear | Request for Last Call review by ARTART Completed: Almost Ready. Reviewer: Eliot Lear. Sent review to list. |
2021-10-03
|
15 | Barry Leiba | Request for Last Call review by ARTART is assigned to Eliot Lear |
2021-10-03
|
15 | Barry Leiba | Request for Last Call review by ARTART is assigned to Eliot Lear |
2021-10-01
|
15 | Jean Mahoney | Request for Last Call review by GENART is assigned to Ines Robles |
2021-10-01
|
15 | Jean Mahoney | Request for Last Call review by GENART is assigned to Ines Robles |
2021-09-30
|
15 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2021-09-30
|
15 | Cindy Morgan | The following Last Call announcement was sent out (ends 2021-10-14): From: The IESG To: IETF-Announce CC: Gorry Fairhurst , draft-ietf-tsvwg-rfc4960-bis@ietf.org, gorry@erg.abdn.ac.uk, martin.h.duke@gmail.com, … The following Last Call announcement was sent out (ends 2021-10-14): From: The IESG To: IETF-Announce CC: Gorry Fairhurst , draft-ietf-tsvwg-rfc4960-bis@ietf.org, gorry@erg.abdn.ac.uk, martin.h.duke@gmail.com, tsvwg-chairs@ietf.org, tsvwg@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (Stream Control Transmission Protocol) to Proposed Standard The IESG has received a request from the Transport Area Working Group WG (tsvwg) to consider the following document: - 'Stream Control Transmission Protocol' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2021-10-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document obsoletes RFC 4960, if approved. It describes the Stream Control Transmission Protocol (SCTP) and incorporates the specification of the chunk flags registry from RFC 6096 and the specification of the I bit of DATA chunks from RFC 7053. Therefore, RFC 6096 and RFC 7053 are also obsoleted by this document, if approved. SCTP was originally designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks. It is also suited to be used for other applications, for example WebRTC. SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users: * acknowledged error-free non-duplicated transfer of user data, * data fragmentation to conform to discovered path maximum transmission unit (PMTU) size, * sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages, * optional bundling of multiple user messages into a single SCTP packet, and * network-level fault tolerance through supporting of multi-homing at either or both ends of an association. The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-bis/ No IPR declarations have been submitted directly on this I-D. |
2021-09-30
|
15 | (System) | Changed action holders to Martin Duke (IESG state changed) |
2021-09-30
|
15 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested::Revised I-D Needed |
2021-09-30
|
15 | Martin Duke | Last call was requested |
2021-09-30
|
15 | Martin Duke | Last call announcement was generated |
2021-09-30
|
15 | Martin Duke | Ballot approval text was generated |
2021-09-30
|
15 | Martin Duke | Ballot writeup was generated |
2021-09-30
|
15 | (System) | Changed action holders to Randall Stewart, Michael Tüxen, Martin Duke, Karen Nielsen (IESG state changed) |
2021-09-30
|
15 | Martin Duke | IESG state changed to Last Call Requested::Revised I-D Needed from AD Evaluation |
2021-09-15
|
15 | (System) | Changed action holders to Martin Duke (IESG state changed) |
2021-09-15
|
15 | Martin Duke | IESG state changed to AD Evaluation from Publication Requested |
2021-09-15
|
15 | Gorry Fairhurst | 1. Summary for draft-ietf-tsvwg-rfc4960-bis The document shepherd is Gorry Fairhurst. The responsible Area Director is Martin Duke . This document specifies the SCTP transport … 1. Summary for draft-ietf-tsvwg-rfc4960-bis The document shepherd is Gorry Fairhurst. The responsible Area Director is Martin Duke . This document specifies the SCTP transport protocol. The intended status listed in the document is "Proposed Standard”. This will obsolete RFC 4960, if approved. It describes the Stream Control Transmission Protocol (SCTP). SCTP was designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks. The transport is also suitable for a range other applications. The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. 2. Review and Consensus WG Summary: The TSVWG working group has worked on this document since 2018, and SCTP contributors have reviewed the specification during that time. In particular, many SCTP implementers have provided detailed comments based on operational experience, that informed RFC8540 which details the core changes in the spec. The document has been relatively stable in the latest versions. All open issues from WGLC has been resolved. The shepherd believes that this document (rev 15) has the support of the TSVWG working group. The basis of the document was set out in RFC 8540, changes also include editorial improvements. All currently known errata to RFC 4960 and related RFCs have been considered in this "bis" document.When published, the document will resolve known issues in the standards-track specification, and improves the quality of the specification of SCTP. It introduces a limited set of modifications to the currently deployed protocol, these changes with respect to RFC4960 are noted in the document. 3. Intellectual Property Each editor has stated that his direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. Since RFC4960 does not change the STCP protocol, relevant IPR would have to be disclosed already for the existing RFCs. 4. Other Points SCTP is implemented in endpoints either in the operating system or a user stack. Running code for SCTP exists in several TCP/IP stacks. All main STCP implementations are expected to comply with 4960.bis. The document is expected to fulfill the requirements of an "Internet Standard" according to RFC 2026 and RFC 7127. The intention of this update is therefore, in part, to ready the SCTP specification for progression along the standards track. The document has been reviewed several time by the work group and in a number of specific detailed reviews (the last during WGLC). This included several complete detailed reviews by the document shepherd. The use of normative language was revised to clarify the meaning and align with usage in other recent TSVWG specifications. There is no specific need for extra expert review (e.g. AAA, DNS, DHCP, XML, or internationalization). The publication of this document will change the status of existing RFCs. These are all listed on the title page header, in the abstract, and in the introduction. The document contains a disclaimer for pre-RFC5378 work. While the RFC4960 authors of the source material are willing to grant the BCP78 rights to the IETF Trust, the document also revises and obsolete older RFCs, incorporating significant amounts of text from those older RFCs. The disclaimer is therefore currently necessary. IANA The IANA Considerations section contains updated text in relation to SCTP registries. It also documents how IANA should update current registries to refer to the new specification. References There is a Non-RFC normative reference to v.42: 'ITU.V42.1994’, as in REF 1 of RFC4960. An informational historic reference to RFC 2960 is included in the acknowledgment to describe the history of the spec. |
2021-09-15
|
15 | Gorry Fairhurst | Responsible AD changed to Martin Duke |
2021-09-15
|
15 | Gorry Fairhurst | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2021-09-15
|
15 | Gorry Fairhurst | IESG state changed to Publication Requested from I-D Exists |
2021-09-15
|
15 | Gorry Fairhurst | IESG process started in state Publication Requested |
2021-09-15
|
15 | Gorry Fairhurst | Tag Doc Shepherd Follow-up Underway cleared. |
2021-09-15
|
15 | Gorry Fairhurst | 1. Summary for draft-ietf-tsvwg-rfc4960-bis The document shepherd is Gorry Fairhurst. The responsible Area Director is Martin Duke . This document specifies the SCTP transport … 1. Summary for draft-ietf-tsvwg-rfc4960-bis The document shepherd is Gorry Fairhurst. The responsible Area Director is Martin Duke . This document specifies the SCTP transport protocol. The intended status listed in the document is "Proposed Standard”. This will obsolete RFC 4960, if approved. It describes the Stream Control Transmission Protocol (SCTP). SCTP was designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks. The transport is also suitable for a range other applications. The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. 2. Review and Consensus WG Summary: The TSVWG working group has worked on this document since 2018, and SCTP contributors have reviewed the specification during that time. In particular, many SCTP implementers have provided detailed comments based on operational experience, that informed RFC8540 which details the core changes in the spec. The document has been relatively stable in the latest versions. All open issues from WGLC has been resolved. The shepherd believes that this document (rev 15) has the support of the TSVWG working group. The basis of the document was set out in RFC 8540, changes also include editorial improvements. All currently known errata to RFC 4960 and related RFCs have been considered in this "bis" document.When published, the document will resolve known issues in the standards-track specification, and improves the quality of the specification of SCTP. It introduces a limited set of modifications to the currently deployed protocol, these changes with respect to RFC4960 are noted in the document. 3. Intellectual Property Each editor has stated that his direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. Since RFC4960 does not change the STCP protocol, relevant IPR would have to be disclosed already for the existing RFCs. 4. Other Points SCTP is implemented in endpoints either in the operating system or a user stack. Running code for SCTP exists in several TCP/IP stacks. All main STCP implementations are expected to comply with 4960.bis. The document is expected to fulfill the requirements of an "Internet Standard" according to RFC 2026 and RFC 7127. The intention of this update is therefore, in part, to ready the SCTP specification for progression along the standards track. The document has been reviewed several time by the work group and in a number of specific detailed reviews (the last during WGLC). This included several complete detailed reviews by the document shepherd. The use of normative language was revised to clarify the meaning and align with usage in other recent TSVWG specifications. There is no specific need for extra expert review (e.g. AAA, DNS, DHCP, XML, or internationalization). The publication of this document will change the status of existing RFCs. These are all listed on the title page header, in the abstract, and in the introduction. The document contains a disclaimer for pre-RFC5378 work. While the RFC4960 authors of the source material are willing to grant the BCP78 rights to the IETF Trust, the document also revises and obsolete older RFCs, incorporating significant amounts of text from those older RFCs. The disclaimer is therefore currently necessary. IANA The IANA Considerations section contains updated text in relation to SCTP registries. It also documents how IANA should update current registries to refer to the new specification. References There is a Non-RFC normative reference to v.42: 'ITU.V42.1994’, as in REF 1 of RFC4960. An informational historic reference to RFC 2960 is included in the acknowledgment to describe the history of the spec. |
2021-09-15
|
15 | Gorry Fairhurst | 1. Summary for draft-ietf-tsvwg-rfc4960-bis The document shepherd is Gorry Fairhurst. The responsible Area Director is Martin Duke . This document specifies the SCTP transport … 1. Summary for draft-ietf-tsvwg-rfc4960-bis The document shepherd is Gorry Fairhurst. The responsible Area Director is Martin Duke . This document specifies the SCTP transport protocol. The intended status listed in the document is "Proposed Standard”. This will obsolete RFC 4960, if approved. It describes the Stream Control Transmission Protocol (SCTP). SCTP was designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks. The transport is also suitable for a range other applications. The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. 2. Review and Consensus WG Summary: The TSVWG working group has worked on this document since 2018, and SCTP contributors have reviewed the specification during that time. In particular, many SCTP implementers have provided detailed comments based on operational experience, that informed RFC8540 which details the core changes in the spec. The document has been relatively stable in the latest versions. All open issues from WGLC has been resolved. The shepherd believes that this document (rev 15) has the support of the TSVWG working group. The basis of the document was set out in RFC 8540, changes also include editorial improvements. All currently known errata to RFC 4960 and related RFCs have been considered in this "bis" document.When published, the document will resolve known issues in the standards-track specification, and improves the quality of the specification of SCTP. It introduces a limited set of modifications to the currently deployed protocol, these changes with respect to RFC4960 are noted in the document. 3. Intellectual Property Each editor has stated that his direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. Since RFC4960 does not change the STCP protocol, relevant IPR would have to be disclosed already for the existing RFCs. 4. Other Points SCTP is implemented in endpoints either in the operating system or a user stack. Running code for SCTP exists in several TCP/IP stacks. All main STCP implementations are expected to comply with 4960.bis. The document is expected to fulfill the requirements of an "Internet Standard" according to RFC 2026 and RFC 7127. The intention of this update is therefore, in part, to ready the SCTP specification for progression along the standards track. The document has been reviewed several time by the work group and in a number of specific detailed reviews (the last during WGLC). This included several complete detailed reviews by the document shepherd. The use of normative language was revised to clarify the meaning and align with usage in other recent TSVWG specifications. There is no specific need for extra expert review (e.g. AAA, DNS, DHCP, XML, or internationalization). The publication of this document will change the status of existing RFCs. These are all listed on the title page header, in the abstract, and in the introduction. The document contains a disclaimer for pre-RFC5378 work. While the RFC4960 authors of the source material are willing to grant the BCP78 rights to the IETF Trust, the document also revises and obsolete older RFCs, incorporating significant amounts of text from those older RFCs. The disclaimer is therefore currently necessary. The IANA Considerations section contains updated text in relation to SCTP registries. It also documents how IANA should update current registries to refer to the new specification. References There is a Non-RFC normative reference to v.42: 'ITU.V42.1994’, as in REF 1 of RFC4960. An informational historic reference to RFC 2960 is included in the acknowledgment to describe the history of the spec. |
2021-09-15
|
15 | Gorry Fairhurst | TSVWG Writeup for draft-ietf-tsvwg-rfc4960-bis Summary The document shepherd is Gorry Fairhurst. The responsible Area Director is Martin Duke . This document specifies the SCTP transport … TSVWG Writeup for draft-ietf-tsvwg-rfc4960-bis Summary The document shepherd is Gorry Fairhurst. The responsible Area Director is Martin Duke . This document specifies the SCTP transport protocol. The intended status listed in the document is "Proposed Standard”. This will obsolete RFC 4960, if approved. It describes the Stream Control Transmission Protocol (SCTP). SCTP was designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks. The transport is also suitable for a range other applications. The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. 2. Review and Consensus WG Summary: The TSVWG working group has worked on this document since 2018, and SCTP contributors have reviewed the specification during that time. In particular, many SCTP implementers have provided detailed comments based on operational experience, that informed RFC8540 which details the core changes in the spec. The document has been relatively stable in the latest versions. All open issues from WGLC has been resolved. The shepherd believes that this document (rev 15) has the support of the TSVWG working group. The basis of the document was set out in RFC 8540, changes also include editorial improvements. All currently known errata to RFC 4960 and related RFCs have been considered in this "bis" document.When published, the document will resolve known issues in the standards-track specification, and improves the quality of the specification of SCTP. It introduces a limited set of modifications to the currently deployed protocol, these changes with respect to RFC4960 are noted in the document. 3. Intellectual Property Each editor has stated that his direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. Since RFC4960 does not change the STCP protocol, relevant IPR would have to be disclosed already for the existing RFCs. 4. Other Points SCTP is implemented in endpoints either in the operating system or a user stack. Running code for SCTP exists in several TCP/IP stacks. All main STCP implementations are expected to comply with 4960.bis. The document is expected to fulfill the requirements of an "Internet Standard" according to RFC 2026 and RFC 7127. The intention of this update is therefore, in part, to ready the SCTP specification for progression along the standards track. The document has been reviewed several time by the work group and in a number of specific detailed reviews (the last during WGLC). This included several complete detailed reviews by the document shepherd. The use of normative language was revised to clarify the meaning and align with usage in other recent TSVWG specifications. There is no specific need for extra expert review (e.g. AAA, DNS, DHCP, XML, or internationalization). The publication of this document will change the status of existing RFCs. These are all listed on the title page header, in the abstract, and in the introduction. The document contains a disclaimer for pre-RFC5378 work. While the RFC4960 authors of the source material are willing to grant the BCP78 rights to the IETF Trust, the document also revises and obsolete older RFCs, incorporating significant amounts of text from those older RFCs. The disclaimer is therefore currently necessary. The IANA Considerations section contains updated text in relation to SCTP registries. It also documents how IANA should update current registries to refer to the new specification. There is a Non-RFC normative reference to v.42: 'ITU.V42.1994’, as in REF 1 of RFC4960. An informational historic reference to RFC 2960 is included in the acknowledgment to describe the history of the spec. |
2021-09-15
|
15 | Michael Tüxen | New version available: draft-ietf-tsvwg-rfc4960-bis-15.txt |
2021-09-15
|
15 | (System) | New version accepted (logged-in submitter: Michael Tüxen) |
2021-09-15
|
15 | Michael Tüxen | Uploaded new revision |
2021-09-03
|
14 | Gorry Fairhurst | Changes were presented after WGLC. These were reviewed at the Interim, no additional comments were seen on the latest submitted revision. WG Shepherd will now … Changes were presented after WGLC. These were reviewed at the Interim, no additional comments were seen on the latest submitted revision. WG Shepherd will now prepare a writeup, confirm IPR, and request Implementation status. |
2021-09-03
|
14 | Gorry Fairhurst | Tag Doc Shepherd Follow-up Underway set. Tag Revised I-D Needed - Issue raised by WG cleared. |
2021-09-03
|
14 | Gorry Fairhurst | IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead |
2021-09-03
|
14 | Gorry Fairhurst | Added to session: interim-2021-tsvwg-02 |
2021-09-02
|
14 | Michael Tüxen | New version available: draft-ietf-tsvwg-rfc4960-bis-14.txt |
2021-09-02
|
14 | (System) | New version accepted (logged-in submitter: Michael Tüxen) |
2021-09-02
|
14 | Michael Tüxen | Uploaded new revision |
2021-09-02
|
13 | Gorry Fairhurst | There were comments during the WGLC asking for clarifications and I now request the editors to prepare a new revision that resolves those issues that … There were comments during the WGLC asking for clarifications and I now request the editors to prepare a new revision that resolves those issues that require text changes. |
2021-09-02
|
13 | Gorry Fairhurst | There were comments during the WGLC asking for clarifications and I now request the editors to prepare a new revision that resolves those issues that … There were comments during the WGLC asking for clarifications and I now request the editors to prepare a new revision that resolves those issues that require text changes. |
2021-09-02
|
13 | Gorry Fairhurst | Tag Revised I-D Needed - Issue raised by WG set. |
2021-09-02
|
13 | Gorry Fairhurst | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2021-08-24
|
13 | Gorry Fairhurst | A message on 18th August started a working group last call for the SCTP.bis draft: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-bis/ This document previously completed a WGLC on -10, and … A message on 18th August started a working group last call for the SCTP.bis draft: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-bis/ This document previously completed a WGLC on -10, and was then subject to an external review that resulted in changes. It is now at revision -13. The WGLC will last for 2 weeks. Please submit any comments to the TSVWG list, including whether you think this is now ready to proceed for publication. |
2021-08-24
|
13 | Gorry Fairhurst | Tag Revised I-D Needed - Issue raised by WGLC cleared. |
2021-08-24
|
13 | Gorry Fairhurst | IETF WG state changed to In WG Last Call from Waiting for WG Chair Go-Ahead |
2021-08-17
|
13 | Michael Tüxen | New version available: draft-ietf-tsvwg-rfc4960-bis-13.txt |
2021-08-17
|
13 | (System) | New version accepted (logged-in submitter: Michael Tüxen) |
2021-08-17
|
13 | Michael Tüxen | Uploaded new revision |
2021-07-23
|
12 | Gorry Fairhurst | Added to session: IETF-111: tsvwg Thu-1200 |
2021-07-23
|
12 | Gorry Fairhurst | Removed from session: IETF-111: tsvwg Mon-1430 |
2021-07-21
|
12 | Gorry Fairhurst | Added to session: IETF-111: tsvwg Mon-1430 |
2021-07-12
|
12 | Michael Tüxen | New version available: draft-ietf-tsvwg-rfc4960-bis-12.txt |
2021-07-12
|
12 | (System) | New version approved |
2021-07-12
|
12 | (System) | Request for posting confirmation emailed to previous authors: Karen Nielsen , Michael Tuexen , Randall Stewart |
2021-07-12
|
12 | Michael Tüxen | Uploaded new revision |
2021-05-07
|
11 | Gorry Fairhurst | WGLC issues were raised that require resolution and/or revised text. |
2021-05-07
|
11 | Gorry Fairhurst | Tag Revised I-D Needed - Issue raised by WGLC set. |
2021-05-07
|
11 | Gorry Fairhurst | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2021-04-18
|
11 | Michael Tüxen | New version available: draft-ietf-tsvwg-rfc4960-bis-11.txt |
2021-04-18
|
11 | (System) | New version approved |
2021-04-18
|
11 | (System) | Request for posting confirmation emailed to previous authors: Karen Nielsen , Michael Tuexen , Randall Stewart |
2021-04-18
|
11 | Michael Tüxen | Uploaded new revision |
2021-03-25
|
10 | Gorry Fairhurst | This email starts a WG Last Call call to determine if this ID is ready to publish: Stream Control Transmission Protocol (SCTP.BIS) draft-ietf-tsvwg-rfc4960-bis-10 … This email starts a WG Last Call call to determine if this ID is ready to publish: Stream Control Transmission Protocol (SCTP.BIS) draft-ietf-tsvwg-rfc4960-bis-10 This document targets PROPOSED STANDARD. The WGLC will end at midnight UTC on 14th April 2021. The document is targeting a PROPOSED STANDARD. This will obsolete 4960 (if approved). Please do read the draft, and send any comments/concerns to either the TSVWG or to the chairs . Best wishes, Gorry, Wes and David (tsvwg co-chairs) |
2021-03-25
|
10 | Gorry Fairhurst | IETF WG state changed to In WG Last Call from WG Document |
2021-03-08
|
10 | Michael Tüxen | New version available: draft-ietf-tsvwg-rfc4960-bis-10.txt |
2021-03-08
|
10 | (System) | New version approved |
2021-03-08
|
10 | (System) | Request for posting confirmation emailed to previous authors: Karen Nielsen , Michael Tuexen , Randall Stewart |
2021-03-08
|
10 | Michael Tüxen | Uploaded new revision |
2021-03-02
|
09 | Gorry Fairhurst | Added to session: IETF-110: tsvwg Mon-1700 |
2021-02-18
|
09 | Michael Tüxen | New version available: draft-ietf-tsvwg-rfc4960-bis-09.txt |
2021-02-18
|
09 | (System) | New version approved |
2021-02-18
|
09 | (System) | Request for posting confirmation emailed to previous authors: Karen Nielsen , Michael Tuexen , Randall Stewart |
2021-02-18
|
09 | Michael Tüxen | Uploaded new revision |
2020-11-30
|
08 | Michael Tüxen | New version available: draft-ietf-tsvwg-rfc4960-bis-08.txt |
2020-11-30
|
08 | (System) | New version approved |
2020-11-30
|
08 | (System) | Request for posting confirmation emailed to previous authors: Karen Nielsen , Randall Stewart , Michael Tuexen |
2020-11-30
|
08 | Michael Tüxen | Uploaded new revision |
2020-07-13
|
07 | Michael Tüxen | New version available: draft-ietf-tsvwg-rfc4960-bis-07.txt |
2020-07-13
|
07 | (System) | New version accepted (logged-in submitter: Michael Tüxen) |
2020-07-13
|
07 | Michael Tüxen | Uploaded new revision |
2020-07-09
|
06 | Gorry Fairhurst | Changed consensus to Yes from Unknown |
2020-07-09
|
06 | Gorry Fairhurst | Intended Status changed to Proposed Standard from None |
2020-07-09
|
06 | Gorry Fairhurst | Added to session: IETF-108: tsvwg Tue-1410 |
2020-04-07
|
06 | Michael Tüxen | New version available: draft-ietf-tsvwg-rfc4960-bis-06.txt |
2020-04-07
|
06 | (System) | New version approved |
2020-04-07
|
06 | (System) | Request for posting confirmation emailed to previous authors: Randall Stewart , Karen Nielsen , Michael Tuexen |
2020-04-07
|
06 | Michael Tüxen | Uploaded new revision |
2020-03-09
|
05 | Michael Tüxen | New version available: draft-ietf-tsvwg-rfc4960-bis-05.txt |
2020-03-09
|
05 | (System) | New version approved |
2020-03-09
|
05 | (System) | Request for posting confirmation emailed to previous authors: Randall Stewart , Karen Nielsen , Michael Tuexen |
2020-03-09
|
05 | Michael Tüxen | Uploaded new revision |
2020-01-27
|
04 | (System) | Document has expired |
2019-07-26
|
04 | Michael Tüxen | New version available: draft-ietf-tsvwg-rfc4960-bis-04.txt |
2019-07-26
|
04 | (System) | New version approved |
2019-07-26
|
04 | (System) | Request for posting confirmation emailed to previous authors: Karen Nielsen , Randall Stewart , Michael Tuexen |
2019-07-26
|
04 | Michael Tüxen | Uploaded new revision |
2019-07-21
|
03 | Magnus Westerlund | Notification list changed to Gorry Fairhurst <gorry@erg.abdn.ac.uk> |
2019-07-21
|
03 | Magnus Westerlund | Document shepherd changed to Gorry Fairhurst |
2019-06-30
|
03 | Michael Tüxen | New version available: draft-ietf-tsvwg-rfc4960-bis-03.txt |
2019-06-30
|
03 | (System) | New version approved |
2019-06-30
|
03 | (System) | Request for posting confirmation emailed to previous authors: Karen Nielsen , Randall Stewart , Michael Tuexen |
2019-06-30
|
03 | Michael Tüxen | Uploaded new revision |
2019-06-29
|
02 | Michael Tüxen | New version available: draft-ietf-tsvwg-rfc4960-bis-02.txt |
2019-06-29
|
02 | (System) | New version approved |
2019-06-29
|
02 | (System) | Request for posting confirmation emailed to previous authors: Karen Nielsen , Randall Stewart , Michael Tuexen |
2019-06-29
|
02 | Michael Tüxen | Uploaded new revision |
2019-03-11
|
01 | Michael Tüxen | New version available: draft-ietf-tsvwg-rfc4960-bis-01.txt |
2019-03-11
|
01 | (System) | New version approved |
2019-03-11
|
01 | (System) | Request for posting confirmation emailed to previous authors: Karen Nielsen , Randall Stewart , Michael Tuexen |
2019-03-11
|
01 | Michael Tüxen | Uploaded new revision |
2018-11-23
|
00 | Michael Tüxen | New version available: draft-ietf-tsvwg-rfc4960-bis-00.txt |
2018-11-23
|
00 | (System) | New version approved |
2018-11-23
|
00 | Michael Tüxen | Request for posting confirmation emailed to submitter and authors: =?utf-8?q?Michael_T=C3=BCxen?= , Randall Stewart , "Karen E. E. Nielsen" |
2018-11-23
|
00 | Michael Tüxen | Uploaded new revision |