Skip to main content

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