IANA Considerations for Network Layer Protocol Identifiers
draft-eastlake-nlpid-iana-considerations-04

[Ballot comment]
While this is a fine document in all other respects, I am concerned by the fact that IETF doesn't seem to have authority to allocate NLPIDs, as the registry is controlled by ISO/ITU-T.

[Ballot comment]
First note that the NLPID was defined before there was an IETF. This is why none of the space was assigned for IETF use.

My understanding (please correct me if I am wrong) is that the reason that we need IANA to assign NLPIDs is that the ISO OSI effort is no longer functionally able to do this. If this is right, then I think that we might as well explicitly say so in the document. Also, if I have this right, then I don't see why we couldn't assign any unused codes which were originally assigned to ISO (leaving the ITU codes for ITU use).

[Ballot comment]
I support Adrian's discuss.

A few nits:

section 2, paragraph 2. 

First sentence - isn't the important point that NLPIDs are used in a number of *IETF* protocols?
The second sentence doesn't quite parse; it is missing the NLPID.  Perhaps appending
"all make use of NLPIDs" would complete the thought?

Section 3 "or are otherwise of interest" seems a bit vague.  Perhaps "or are identified
by the IETF liaison to ISO/IEC JTC1 SC6" would capture the idea more clearly.

[Ballot discuss]
Two quick discussion points that I hope we can clear with an email exchange. I am probably missing something since this I-D has clearly been widely discussed by the eminences.

Section 2.3 says:

  A limited number of code points are available that could be allocated
  by IANA under [ISO9577]. Because of this, it is desirable, where
  practical, to use code point 0x80, as discussed in Section 2.2 above,
  or to get code points allocated from the ranges categorized to other
  organizations.

But then also says:

  The table below, which includes two new code point allocations made
  by this document, shows those still available.

      Code Point  Status
      ----------  --------
      0xC0        TRILL [TRILL]
      0xC1        IEEE 802.1aq [802.1aq]

So I assume that it is "not practical" to allocate these code points under 0x80. Should the I-D not give a hint as to why this is not practical so that it does not appear self-inconsistent?

---

The allocation policy is shown as Standards Action, yet one of the references for the new allocation is not an IETF document, and the other is an I-D that is not yet an RFC (I think it is currently in IETF last call).

This I-D is, itself, not adeqaate to count as a Standards Track document for the 802.1aq because it is a BCP. I also don't understand why IEEE can't look after their own allocations under 0x80 (but perhaps this comes under my first discussion point).

I suggest that there is no need for early allocation for Trill. That I-D can look after its own allocation.

[Ballot discuss]
This is a fine document, but I would like to hear an answer to the following question before recommending its approval (I fully admit my ignorance on the matter):

Does IETF have authority to direct IANA to allocate NLPIDs from the registry controlled by ISO/IEC?

IANA comments:

Upon approval of this document, the IANA will create the following
registry at
http://www.iana.org/assignments/TBD

Registry Name: Network Layer Protocol Identifiers (NLPIDs)
Registration Procedures: Standards Action

Note: This registry is a joint registry with ISO9577. The liaison to ISO/IEC
JTC1 SC6 and/or the IAB will be notified of additions/modifications.

Initial contents of this registry will be:

Code Point Use Reference
---------- -------- --------
0x00 Null
0x80 IEEE SNAP [RFC-eastlake-nlpid-iana-considerations-03]
0x81 ISO CLNP [ISO-CLNP (Connectionless Network Protocol)]
0x82 ISO ES-IS [ISO-ES-IS]
0x83 IS-IS [RFC-1195]
0x8E IPv6 [RFC-2460]
0xC0 TRILL [draft-ietf-trill-rbridge-protocol]
0xC1 IEEE 802.1aq [IEEE-802.1aq]
0xC2-0xCB Available [RFC-eastlake-nlpid-iana-considerations-03]
0xCC IPv4 [RFC-791]
0xCD-0xCE Available [RFC-eastlake-nlpid-iana-considerations-03]
0xCF PPP [RFC-1661]

We understand the above to be the only IANA Action for this document.

PROTO write-up by Donald:

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

Donald Eastlake 3rd is the Document Shepherd. He has personally
reviewed the -02 version of the document and believes that it is ready
for forwarding to the IESG for publication.

  (1.b)  Has the document had adequate review both from key members of
      the interested community and others?  Does the Document Shepherd
      have any concerns about the depth or breadth of the reviews that
      have been performed?

This document has been circulated among the TRILL and IS-IS working
group chairs, the Internet and Routing ADs, the IETF Chair, the Editor
of IEEE P802.1aq, IANA, the IETF Liaisons to IEEE 802.1 and ISO/IEC
JTC1 SC6, and other technical experts. It has been adjusted based on
their comments. The shepherd believes this review is sufficient for
the document to proceed to sponsoring AD review and, after correcting
any problems found at that stage, to IETF 4 week Last Call.

  (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.

  (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 interested community has discussed those issues and has
      indicated that it still wishes to advance the document, detail
      those concerns here.

No special concerns except that the document is a little unusual in
that it provides the IANA procedures for causing values to be
registered in a registry maintained by another organization. Also, as
a courtesy to and at the request of the IEEE P802.1aq Editor, it
includes the allocation of a code point for IEEE P802.1aq.

  (1.e)  How solid is the consensus of the interested community behind
      this document?  Does it represent the strong concurrence of a few
      individuals, with others being silent, or does the interested
      community as a whole understand and agree with it?

There is a solid consensus within the community of interest.

  (1.f)  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
      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?

The shepherd has verified that the document satisfies all ID
nits. There are no special formal review criteria for this document.

  (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].

References are split as required.

  (1.i)  Has the Document Shepherd verified that the document IANA
      consideration 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 suggested a reasonable name for the new registry?  See
      [I-D.narten-iana-considerations-rfc2434bis].  If the document
      describes an Expert Review process has the Shepherd conferred
      with the Responsible Area Director so that the IESG can appoint
      the needed Expert during the IESG Evaluation?

This entire document provides IANA considerations for NLPIDs. It does
not create an IANA registry as the registry is maintained by ISO/IEC
JTC1 SC6. It does create an IANA web page for tracking purposes and
gives the intitial contents and clear update procedures for that IANA
web page.

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

There are no such sections in this document.

  (1.k)  The IESG approval announcement includes a Document
      Announcement Write-Up.  Please provide such a Document
      Announcement Writeup?  Recent examples can be found in the
      "Action" announcements for approved documents.

Technical Summary

  Network Layer Protcol IDs (NLPIDs) are used in a number of
  protocols that the IETF has specified or is extending. Examples
  include the NBMA Next Hop Resolution Protocol and the IS-IS
  Protocols Supported TLV. The registry of these values is maintained
  by ISO/IEC. This document provides the IANA Considerations
  procedures for originating and documenting the allocation of an
  NLPID from within the IETF.

Working Group Summary

  This document was not produced by an IETF working group but is
  supported by a clear consensus of the community of interest.

Document Quality

  The document has been reviewed by the IETF TRILL and IS-IS working
  group chairs, the Internet and Routing ADs, the IETF Chair, the
  Editor of IEEE P802.1aqt, IANA, the IETF Liaison to ISO/IEC JTC1
  SC6, and other technical experts. Document quality is high.