IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters
draft-eastlake-ethernet-iana-considerations-08

[Ballot discuss]
I doubt that having IANA archive IDs has IETF consensus - if you do, I'd like to understand why.  (I expect the -08 version of the draft will clear this discuss based on email with author)

[Ballot discuss]
This deprecates an portion of 2153 so it needs to at least be called out that it updates 2153.

I doubt that having IANA archive IDs has IETF consensus - if you do, I'd like to understand why. However, it does not really look like IANA archiving these  is needed - given the ID could be empty and as far as I can tell, the allocation would still be approved, why not just drop the requirement for a draft? Of if what folks wanted was to have something that explained what the code point was for, why not ask for specification required? I'm don't have any strong opinion on who this should  be resolved, perhaps the current drafts is fine, but I do not understand the goals that are trying to be achieved with the current text around what documents are needed for an allocation.

[Ballot discuss]
Disagree with Lars about the use of an Internet Draft - one of the whole purposes behind "Expert Review" is that the numbers can be assigned before an RFC is approved when necessary. I am unsure, however, about the policy asking IANA to archive an ID. If IANA is OK with that, it seems a fine thing to do as long as we aren't crossing any sort of odd legal barriers with respect to our IDs being forced to "expire" or not officially. Aside of this perhaps arcane case, its actually a moot point as between tools.ietf.org and a variety of other sites we all know that IDs are essentially permanent anyway. Noting version of ID is important of course, and I do think that IANA already does this in many cases.

I do have a concern here:

  If the allocation is based on IESG Ratification the procedure
        starts with the first two steps above for Expert Review. If the
        Expert disapproves the application, they simply inform IANA;
        however, if the Expert believes the application should be
        approved, the Expert will forward the application together with
        their reasons for approval to the IESG which must ratify the
        approval for the allocation to be granted.

For a very large allocation, perhaps we should give the expert the ability to "pass the buck" of responsibility to the IESG rather than forcing him or her to either be strictly for or against. Some slight wording such as this could fix this, e.g.,

"If the Expert believes the application should be approved, or is unsure whether it should be denied outright, the Expert will forward the application together with their analysis to the IESG which must either ratify the approval recommendation, or make its own decision on whether to approve or deny the allocation."

[Ballot comment]
Comment on the same piece of text:
  Also, since the first bullet talks about standards, do you mean an
  IETF Standards Track RFC, or do you mean any standard (e.g., by
  another body) published as an RFC (e.g., on the independent stream)?


Section 2.1.2, paragraph 14:
>          require Expert Review.

  Who is the expert? Do we need a management item to assign one?

[Ballot discuss]
Section 2.1.2, paragraph 9:
>      o  must be for standards purposes,
...
>      o  must be documented in an Internet Draft or RFC.

  DISCUSS: Since Internet Drafts are ephemeral and hence aren't a
  permanent form of documentation, we should require an RFC here. (And
  elsewhere in the document where the same wording is used.)

Waiting for IANA to acknowledge that procedures described in draft-06 are acceptable to IANA. Messages on this respect were sent by the author on 4/22 and 5/23

IANA Last Call comments:

IANA has sent extensive comments to the Author and responsible
Area Director for this document. Comments included:

1. Possible title change to make it more clear what the document is
about
2. The registration procedures throughout the document need to be
more clear (section 2.1.2, section 4 and section 5.1)
3. Possible format change in section 2.2.2
4. For section 5.1, IANA would like to see this stick more to the
procedures outlined in RFC2434bis. Instead of Expert Pool,
categorize as Expert Review. This section needs further discussion.
5. Minor editorial comments

It is clear from IANA's comments that a new version of this
document will be needed. IANA will continue to work with the
document author and responsible AD to make sure the IANA
instructions in this document are satisfactory.