Updates to the IS-IS TLV Codepoints Registry
draft-ietf-isis-tlv-codepoints-02

[Ballot comment]
Get-ART reviewer Robert Sparks concurs with Pete's observation about the weirdness of PS classification, but it may not be so important (IMHO) to fix this. Lets focus on other things, like Adrian's Discuss.

[Ballot discuss]
After following the long email thread and discussing this with the document editor, I come to the following proposed changes.  The net effect is to note that with "Expert Review" the concept of "Early Allocation" is not needed because the Designated Experts are empowered to grant assignments when they think appropriate. What *is* useful, however, is to give those experts some guidance about what is and is not appropriate.

That leads me to the following...

Abstract
OLD
  This document recommends some editorial changes to the IANA IS-IS TLV
  Codepoints registry to more accurately document the state of the
  protocol.  It also defines early allocation procedures for codepoints
  managed by the registry.
NEW
  This document recommends some editorial changes to the IANA IS-IS TLV
  Codepoints registry to more accurately document the state of the
  protocol.  It also sets out new guidelines for Designated Experts to
  apply when reviewing allocations from the registry.
END

Section 1
OLD
  The IS-IS TLV Codepoints registry was created by [RFC3563] and
  extended by [RFC6233].  As IS-IS related RFCs are published the
  codepoints required for the protocol extensions are added to the IANA
  managed registry.
NEW
  The IS-IS TLV Codepoints registry was created by [RFC3563] and
  extended by [RFC6233].  The assignment policy for the registry is
  "Expert Review" as defined in [RFC5226].  As IS-IS related documents
  are developed, the codepoints required for the protocol extensions
  are reviewed by the Designated Experts and added to the IANA managed
  registry.  As these documents are published as RFCs, the registries
  are updated to reference the relevant RFC.
END

Section 1
OLD
  There is a need to support early allocation of codepoints defined in
  drafts which seem likely to eventually gain WG approval.  The
  procedure for obtaining early allocation of codepoints is described.
NEW
  In some cases there is a need to allocate codepoints defined in
  Internet-Drafts which seem likely to eventually gain WG approval
  without waiting for those drafts to be published as RFCs.  This can
  be achieved using Expert Review, and this document sets out guidance
  for the Designated Experts to apply when reviewing allocations from
  the registry.
END

Section 4
OLD
4.  Early Allocation of Codepoints

  When new drafts are introduced requiring new codepoints, it is
  advantageous to have the ability to do early allocation of
  codepoints.  The reasons this is advantageous and the process to do
  so is described in [RFC7120].  However, [RFC7120] procedures do not
  apply to registries such as the IS-IS TLV Codepoints Registry which
  utilize "Expert Review" allocation policy.  In such cases what is
  required is that a request be made to the designated experts.  The
  following procedures are defined.  Note these procedures apply
  specifically to the IS-IS TLV Codepoints registry.  This document is
  not defining a general early allocation process for other Expert
  Review registries.

  1.  In order to qualify for early allocation a draft MUST be accepted
      as a WG document

  2.  The author(s) of the draft MAY request early allocation of
      codepoints to the chair(s) of the WG in which the document is
      submitted

  3.  The WG chair(s) gauge whether there is consensus within the WG
      that early allocation is appropriate for the given document and
      that the conditions for early allocation specified in [RFC7120]
      Section 2 are satisfied.  If so the request is forwarded to the
      Area Director(s).

  4.  If the Area Director(s) approve, the request is forwarded to the
      Designated Experts for their approval.

  5.  Once the Designated Experts have granted approval IANA will
      update the registry marking the allocated codepoints as
      "Temporary" following the procedures specified in [RFC7120]
      Section 3.1
NEW
4.  Guidance for Designated Experts

  When new drafts are introduced requiring new codepoints, it is
  advantageous to be able to allocate codepoints without waiting for
  them to progress to RFC.  The reasons this is advantageous is
  described in [RFC7120].  However, [RFC7120] procedures for early
  allocation do not apply to registries such as the IS-IS TLV
  Codepoints Registry which utilize "Expert Review" allocation policy.
  In such cases what is required is that a request be made to the
  Designated Experts who may approve the assignments according to the
  guidance that has been established for the registry concerned.

  The following guidance applies specifically to the IS-IS TLV
  Codepoints registry.

  1.  Application for a codepoint allocation may be made to the
      Designated Experts at any time.

  2.  The Designated Experts should only consider requests that
      arise from Internet-Drafts that have already been accepted as
      Working Group documents or that are planned for progression as
      AD Sponsored documents in the absence of a suitably chartered
      Working Group.

  3.  In the case of Working Group documents, the Designated Experts
      should check with the Working Group chairs that there is
      consensus within the Working Group to make the allocation at this
      time.  In the case of AD Sponsored documents, the Designated
      Experts should check with the AD for approval to make the
      allocation at this time.

  4.  The Designated Experts should then review the assignment requests
      on their technical merit.  The Designated Experts should not seek
      to overrule IETF consensus, but may raise issues for further
      consideration before the assignments are made.

  5.  Once the Designated Experts have granted approval IANA will
      update the registry marking the allocated codepoints with a
      reference to the associated document as normal.
END

[Ballot comment]
Thank you for taking the time to write this document.

---

I don't understand why this document includes a "pre-November 10, 2008"
disclaimer. Could that safely be left out?

---

The Abstract says that the document "recommends" some changes. That may
have been true as an I-D, but will not be true as a published RFC.

Probably s/recommends/makes/

[Ballot comment]
I'm a little confused about the state in which this document leaves the registration policies, so maybe someone can clarify. I think what this document says is that to obtain an early allocation in the IS-IS TLV Codepoints registry, an IETF WG document is necessary (along with a bunch of other things including WG consensus, AD approval, and DE approval). But since the policy for non-early (final) allocations is expert review and there does not seem to be any explicit document requirement, it's possible that a final allocation can be made based on an individual draft or a document from another SDO, or with no document at all. Is that the desired outcome? It seems a bit backwards in that on paper it might be easier to get a final allocation than an early one.

IESG/Author/WG Chairs:

IANA has reviewed draft-ietf-isis-tlv-codepoints-00.  Authors should review the comments and questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

QUESTION: Would it be appropriate to 1) make this document an additional reference for and 2) add a note to the top of the IS-IS TLV Codepoints registry that says, "Early allocation procedures are defined in [this document]"?

If so, does this apply only to the registry called "TLV Codepoints Registry," or to other registries at http://www.iana.org/assignments/isis-tlv-codepoints?

QUESTION: Can you confirm that the value listed for "64-bit Administrative Tag Sub-TLV" in section 3 should actually be "2"?

IANA understands that, upon approval of this document, there are two actions which IANA must complete.

First, there is an existing common sub-TLV registry for Sub-TLVs for TLV 22, 141, and 222 located at:

http://www.iana.org/assignments/isis-tlv-codepoints/

IANA understands that this existing registry is to be extended to include Sub-TLVs 23 and 223. IANA understands that this affects the title of the registry and the list of parameters in the registry. IANA also understands that no other changes are to be made to the registry including the fact that the registry is to be maintained through Expert Review as defined in RFC 5226.

Second, there are currently separate sub-TLV registries for TLVs 135, 235, 236, and 237 at

http://www.iana.org/assignments/isis-tlv-codepoints/

IANA understands that these four existing sub-TLV registries will be combined into a single registry entitled "Sub-TLVs for TLVs 135, 235, 236, and 237," also to be located at

http://www.iana.org/assignments/isis-tlv-codepoints/

IANA understands that the registration rules for the new combined registry is to be the same as the existing sub-registries.

We understand that the author and shepherd are both designated experts for these registries.

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 only to confirm what actions will be performed.

    As required by RFC 4858, this is the current template for the Document
    Shepherd Write-Up.

    Changes are expected over time. This version is dated 24 February 2012.

    (1) What type of RFC is being requested (BCP, Proposed Standard, Internet
        Standard, Informational, Experimental, or Historic)? Why is this the
        proper type of RFC? Is this type of RFC indicated in the title page
        header?

Proposed Standard.

    (2) 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 recommends some editorial changes to the IANA IS-IS TLV Codepoints
registry to more accurately document the state of the protocol.  It also defines
early allocation procedures for codepoints managed by the registry.

    Working Group Summary:

Nothing worth noting.

    Document Quality:

Quality is good, document simply re-organizes IANA registries.

    Personnel:

Shepherd: Christian Hopps.
AD: Alia Atlas.

    (3) Briefly describe the review of this document that was performed by the
        Document Shepherd. If this version of the document is not ready for
        publication, please explain why the document is being forwarded to the
        IESG.

Reviewed proposed consolidation of IANA registries. Everything is as should be.

    (4) Does the document Shepherd have any concerns about the depth or breadth
        of the reviews that have been performed?

No.

    (5) Do portions of the document need review from a particular or from
        broader perspective, e.g., security, operational complexity, AAA, DNS,
        DHCP, XML, or internationalization? If so, describe the review that took
        place.

No.

    (6) Describe any specific concerns or issues that the Document Shepherd has
        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.
None.

    (7) Has each author confirmed that any and all appropriate IPR disclosures
        required for full conformance with the provisions of BCP 78 and BCP 79
        have already been filed. If not, explain why?

Nothing new to claim IPR on is introduced by this document.

    (8) Has an IPR disclosure been filed that references this document? If so,
        summarize any WG discussion and conclusion regarding the IPR
        disclosures.

No.

    (9) 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?

Mostly Silent.

    (10) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in separate
        email messages to the Responsible Area Director. (It should be in a
        separate email because this questionnaire is publicly available.)

No.

    (11) Identify any ID nits the Document Shepherd has found in this
        document. (See http://www.ietf.org/tools/idnits/ and the
        Internet-Drafts Checklist). Boilerplate checks are not enough; this
        check needs to be thorough.

None.

    (12) Describe how the document meets any required formal review criteria,
        such as the MIB Doctor, media type, and URI type reviews.

The document has been reviewed by the IANA experts responsible for the
registries that it affects.

    (13) Have all references within this document been identified as either
        normative or informative?

Yes.

    (14) 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 plan for their completion?

No.

    (15) Are there downward normative references references (see RFC 3967)? If
        so, list these downward references to support the Area Director in the
        Last Call procedure.

No.

    (16) Will publication of this document change the status of any existing
        RFCs? Are those RFCs listed on the title page header, listed in the
        abstract, and discussed in the introduction? If the RFCs are not listed
        in the Abstract and Introduction, explain why, and point to the part of
        the document where the relationship of this document to the other RFCs
        is discussed. If this information is not in the document, explain why
        the WG considers it unnecessary.

No.

    (17) Describe the Document Shepherd's review of the IANA considerations
        section, especially with regard to its consistency with the body of the
        document. Confirm that all protocol extensions that the document makes
        are associated with the appropriate reservations in IANA
        registries. Confirm that any referenced IANA registries have been
        clearly identified. Confirm that newly created IANA registries include
        a detailed specification of the initial contents for the registry, that
        allocations procedures for future registrations are defined, and a
        reasonable name for the new registry has been suggested (see RFC 5226).

This document is entirely concerned with IANA registries. So the review was
entirely with respect to IANA. The document is clear in the changes it is making.

    (18) List any new IANA registries that require Expert Review for future
        allocations. Provide any public guidance that the IESG would find
        useful in selecting the IANA Experts for these new registries.

The document creates a new Prefix Reachability sub-TLV registry which
consolidates and replaces multiple sub-TLVs registries (per-TLV). The experts
for the new registry are the same as the experts for the registries being
replaced.

    (19) Describe reviews and automated checks performed by the Document
        Shepherd to validate sections of the document written in a formal
        language, such as XML code, BNF rules, MIB definitions, etc.

N/A.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Updates to IS-IS TLV Codepoints Registry) to Proposed Standard


The IESG has received a request from the IS-IS for IP Internets WG (isis)
to consider the following document:
- 'Updates to IS-IS TLV Codepoints Registry'
  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
ietf@ietf.org mailing lists by 2014-07-25. 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 recommends some editorial changes to the IANA IS-IS TLV
  Codepoints registry to more accurately document the state of the
  protocol.  It also defines early allocation procedures for codepoints
  managed by the registry.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-isis-tlv-codepoints/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-isis-tlv-codepoints/ballot/


No IPR declarations have been submitted directly on this I-D.