Stream Control Transmission Protocol (SCTP) Chunk Flags Registration
RFC 6096
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2015-10-14
|
02 | (System) | Notify list changed from tsvwg-chairs@ietf.org, draft-ietf-tsvwg-sctp-chunk-flags@ietf.org to (None) |
|
2012-08-22
|
02 | (System) | post-migration administrative database adjustment to the Yes position for Jari Arkko |
|
2012-08-22
|
02 | (System) | post-migration administrative database adjustment to the No Objection position for Dan Romascanu |
|
2012-08-22
|
02 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
|
2011-01-26
|
02 | Cindy Morgan | State changed to RFC Published from RFC Ed Queue. |
|
2011-01-26
|
02 | Cindy Morgan | [Note]: changed to 'RFC 6096' |
|
2011-01-25
|
02 | (System) | RFC published |
|
2010-11-01
|
02 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
|
2010-11-01
|
02 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
|
2010-11-01
|
02 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
|
2010-11-01
|
02 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2010-10-18
|
02 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
|
2010-10-15
|
02 | (System) | IANA Action state changed to In Progress |
|
2010-10-15
|
02 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2010-10-15
|
02 | Amy Vezza | IESG has approved the document |
|
2010-10-15
|
02 | Amy Vezza | Closed "Approve" ballot |
|
2010-10-15
|
02 | Lars Eggert | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup by Lars Eggert |
|
2010-10-14
|
02 | Russ Housley | [Ballot discuss] Suresh Krishnan posted a Gen-ART Review on 5 October 2010, and the authors responded to the review immediately. However, I do not … [Ballot discuss] Suresh Krishnan posted a Gen-ART Review on 5 October 2010, and the authors responded to the review immediately. However, I do not think that the concerns with the IANA Considerations have been resolved. I think a simple update to Section 3 will resolve the issue. Suresh Krishnan said: > > Even though this is under the IANA considerations section, the > instructions seem to be aimed not at IANA but at protocol extension > designers. Where does the required documentation need to be? In the > relevant draft or in an IANA registry. The only IANA instruction I > can see is the sentence beginning with "IANA creates for each new > chunk type a registration table for the chunk flags for this type." The authors said in reply: > > Section 3.1 is the updated section 14.1 of RFC 4960. This is > explained in Section 3: > > Section 3.1 describes the updated procedure for chunk type > registration and replaces Section 14.1 of [RFC4960]. Section 3.2 > adds a new procedure for chunk flag registration to the updated > section 14.1 of [RFC4960]. > > IANA is requested to create an SCTP Chunk Flag registry. The > initial contents of the registry should be assigned using the > values specified in Section 3.3. > > So what we expect from IANA when this ID is approved is specified > in section 3.3. I suggest that Section 3 should say: Section 3.1 provides the updated procedure for SCTP Chunk Type registration; it replaces Section 14.1 of [RFC4960]. Section 3.2 provides a new procedure for SCTP Chunk Flag registration. A registry entry must be created for each SCTP Chunk Type. Section 3.3 provides the SCTP Chunk Flag registry values for the SCTP Chunk Types specified in [RFC4960]. |
|
2010-10-14
|
02 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
|
2010-10-14
|
02 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu |
|
2010-10-08
|
02 | (System) | Removed from agenda for telechat - 2010-10-07 |
|
2010-10-07
|
02 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to Yes from Discuss by Jari Arkko |
|
2010-10-07
|
02 | (System) | New version available: draft-ietf-tsvwg-sctp-chunk-flags-02.txt |
|
2010-10-07
|
02 | Cindy Morgan | State changed to IESG Evaluation::AD Followup from In Last Call by Cindy Morgan |
|
2010-10-07
|
02 | Dan Romascanu | [Ballot comment] I support Jari's DISCUSS. |
|
2010-10-07
|
02 | Dan Romascanu | [Ballot discuss] This document is fine, and I support its approval, provided that the issues raised in the Jari's DISCUSS and the issue here are … [Ballot discuss] This document is fine, and I support its approval, provided that the issues raised in the Jari's DISCUSS and the issue here are considered for edits (RFC Editor note would be fine). Section 3.2, point b) seems to me incomplete when it describes the behavior of implementations that do not support a new flag only as a receiver and not as a sender. A small edit on the lines of the one suggested below would clarify the issue: s/It MUST be considered that implementations not supporting the flag will just ignore it/It MUST be considered that implementations not supporting the flag will send '0' on transmit and just ignore it on receipt. |
|
2010-10-07
|
02 | Dan Romascanu | [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu |
|
2010-10-06
|
02 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
|
2010-10-06
|
02 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded by Sean Turner |
|
2010-10-06
|
02 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
|
2010-10-06
|
02 | Jari Arkko | [Ballot discuss] This document is doing exactly the right thing and its good that we update the IANA rules on Chunk Flags. However -- and … [Ballot discuss] This document is doing exactly the right thing and its good that we update the IANA rules on Chunk Flags. However -- and I feel a bit silly raising this -- the motivation at the beginning just seems wrong. The document says: Without publication of this document, the only way to have done this would have been to obsolete [RFC4960], which is not appropriate. I do not think obsoleting RFC 4960 would have been necessary at all. As an example, even this draft just does an Updates: RFC 4960, not Obsoletes: RFC 4960. As this is a small issue I do not plan to block the publication because of this matter, but I did want to raise a Discuss so that we can talk about it on the IESG telechat and hopefully the responsible AD will place an RFC Editor note to correct this. |
|
2010-10-06
|
02 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to Discuss from No Objection by Jari Arkko |
|
2010-10-06
|
02 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko |
|
2010-10-06
|
02 | Amanda Baber | Upon approval of this document, IANA understands that a single action must be completed by IANA. IANA is to create a new sub-registry in the … Upon approval of this document, IANA understands that a single action must be completed by IANA. IANA is to create a new sub-registry in the Stream Control Transmission Protocol (SCTP) Parameters registry located at: http://www.iana.org/assignments/sctp-parameters The new registry will be called the SCTP Chunk Flags Registry and will consist of a registration for each new chunk type and an associated registration table for the chunk type. The values in the registration table must be one of 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, or 0x80, which must be unique within the chunk flag values for the specific chunk type. Registration procedure: new chunk types are created through IETF Review action, as defined in RFC 5226. New chunk flag values within each chunk type require an RFC to be created. This document, upon approval, creates twenty new chunk flags, as documented in sections 3.3.1 through 3.3.20 of the current draft. Of these initial registrations in the new registry all but the DATA Chunk Flags, ABORT Chunk Flags, and the SHUTDOWN COMPLETE Chunk Flags have empty chunk flag value tables. IANA understands that the creation of this new registry is the only action required upon approval of this document. |
|
2010-10-06
|
02 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks |
|
2010-10-06
|
02 | Russ Housley | [Ballot discuss] Suresh Krishnan posted a Gen-ART Review on 5 October 2010, and the authors responded to the review immediately. However, I do not … [Ballot discuss] Suresh Krishnan posted a Gen-ART Review on 5 October 2010, and the authors responded to the review immediately. However, I do not think that the concerns with the IANA Considerations have been resolved. I think a simple update to Section 3 will resolve the issue. Suresh Krishnan said: > > Even though this is under the IANA considerations section, the > instructions seem to be aimed not at IANA but at protocol extension > designers. Where does the required documentation need to be? In the > relevant draft or in an IANA registry. The only IANA instruction I > can see is the sentence beginning with "IANA creates for each new > chunk type a registration table for the chunk flags for this type." The authors said in reply: > > Section 3.1 is the updated section 14.1 of RFC 4960. This is > explained in Section 3: > > Section 3.1 describes the updated procedure for chunk type > registration and replaces Section 14.1 of [RFC4960]. Section 3.2 > adds a new procedure for chunk flag registration to the updated > section 14.1 of [RFC4960]. > > IANA is requested to create an SCTP Chunk Flag registry. The > initial contents of the registry should be assigned using the > values specified in Section 3.3. > > So what we expect from IANA when this ID is approved is specified > in section 3.3. I suggest that Section 3 should say: Section 3.1 provides the updated procedure for SCTP Chunk Type registration; it replaces Section 14.1 of [RFC4960]. Section 3.2 provides a new procedure for SCTP Chunk Flag registration. A registry entry must be created for each SCTP Chunk Type. Section 3.3 provides the SCTP Chunk Flag registry values for the SCTP Chunk Types specified in [RFC4960]. |
|
2010-10-06
|
02 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley |
|
2010-10-06
|
02 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded by Stewart Bryant |
|
2010-10-06
|
02 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded by Gonzalo Camarillo |
|
2010-10-05
|
02 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded by Peter Saint-Andre |
|
2010-10-05
|
02 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms |
|
2010-10-04
|
02 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel |
|
2010-09-25
|
02 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Love Astrand |
|
2010-09-25
|
02 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Love Astrand |
|
2010-09-23
|
02 | Amy Vezza | Last call sent |
|
2010-09-23
|
02 | Amy Vezza | State changed to In Last Call from Last Call Requested by Amy Vezza |
|
2010-09-23
|
02 | Lars Eggert | [Ballot Position Update] New position, Yes, has been recorded for Lars Eggert |
|
2010-09-23
|
02 | Lars Eggert | Ballot has been issued by Lars Eggert |
|
2010-09-23
|
02 | Lars Eggert | Created "Approve" ballot |
|
2010-09-23
|
02 | Lars Eggert | Placed on agenda for telechat - 2010-10-07 by Lars Eggert |
|
2010-09-23
|
02 | Lars Eggert | Last Call was requested by Lars Eggert |
|
2010-09-23
|
02 | (System) | Ballot writeup text was added |
|
2010-09-23
|
02 | (System) | Last call text was added |
|
2010-09-23
|
02 | (System) | Ballot approval text was added |
|
2010-09-23
|
02 | Lars Eggert | State changed to Last Call Requested from AD Evaluation by Lars Eggert |
|
2010-09-23
|
02 | Lars Eggert | State changed to AD Evaluation from Publication Requested by Lars Eggert |
|
2010-09-23
|
02 | Lars Eggert | Responsible AD has been changed to Lars Eggert from David Harrington by Lars Eggert |
|
2010-09-22
|
02 | Amy Vezza | This is the WG shepherd writeup for draft-ietf-tsvwg-sctp-chunk-flags for publication as Proposed Standard: (1.a) Who is the Document Shepherd for this document? Has the … This is the WG shepherd writeup for draft-ietf-tsvwg-sctp-chunk-flags for publication as Proposed Standard: (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Gorry Fairhurst is the shepherd and he thinks it is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Version -01 was reviewed. The current draft (-01) defines a new IANA registration procedure missing in the original specification of SCTP., and which is expected to be used by other RFCs. This became a work item on March 22, 2010; the WGLC ended 6th September 2010. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? No. IANA have been consulted and will anyway perform a formal review. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No concerns with the new IANA mechanisms. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The latest version has been discussed by the TSVWG and there was consensus to publish the updated document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. Yes, and this document is intended for Proposed standard, updating RFC 4960. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. There are no informative references. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? Yes. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Not appropriate. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document defines the procedure for registering chunk flags with the Internet Assigned Numbers Authority (IANA) for the Stream Control Transmission Protocol (SCTP). It updates RFC 4960, and also defines the IANA registry for contents for currently defined chunk types. It does not change SCTP in any other way. Working Group Summary This document is a minor update to SCTP that was required to progress other work on SCTP. Document Quality This document has been reviewed by the WG, and there was WG consensus for publishing this version of the document. Personnel Gorry Fairhurst is the document shepherd. ---------------------------------------------------- |
|
2010-09-22
|
02 | Amy Vezza | Draft Added by Amy Vezza in state Publication Requested |
|
2010-09-22
|
02 | Amy Vezza | [Note]: 'Gorry Fairhurst (gorry@erg.abdn.ac.uk) is the document shepherd' added by Amy Vezza |
|
2010-09-07
|
01 | (System) | New version available: draft-ietf-tsvwg-sctp-chunk-flags-01.txt |
|
2010-06-06
|
00 | (System) | New version available: draft-ietf-tsvwg-sctp-chunk-flags-00.txt |