IANA Rules for the Protocol for Carrying Authentication for Network Access (PANA)
draft-arkko-pana-iana-02

[Ballot comment]
The Gen-ART Review by Wassim Haddad on 2010-03-09 included very
  minor editorial comments.  Please consider them if an update to
  this document is needed for any reason.

[Ballot comment]
16 experimental message types look like a lot. I can imagine a single experiment that might need 4 or 5.

The risk, always, is that there are enough codepoints that people start to have expectations about their persistence.

If you were able to reduce this pool I would not be unhappy.

IANA comments:

Action 1:

Upon approval of this document, IANA will make the following changes in
the "Message Types" registry at
http://www.iana.org/assignments/pana-parameters/pana-parameters.xhtml

OLD:

Range Registration Procedures Notes
------- ----------------------- ------------
1-65519 IETF Consensus
65520-65535 IANA does not assign Outlined in [RFC3692]

NEW:

Range Registration Procedures Notes
------- ----------------------- ------------
1-65519 IETF Review or IESG Approval
65520-65535 IANA does not assign Outlined in [RFC3692]


Action 2:

Upon approval of this document, IANA will make the following changes in
the "Message Flags" registry at
http://www.iana.org/assignments/pana-parameters/pana-parameters.xhtml

OLD:

Registration Procedures
Standards Action

NEW:

Registration Procedures
Standards Action or IESG Approval


Action 3:

Upon approval of this document, IANA will make the following changes in
the "AVP Flags" registry at
http://www.iana.org/assignments/pana-parameters/pana-parameters.xhtml

OLD:

Registration Procedures
Standards Action

NEW:

Registration Procedures
Standards Action or IESG Approval


Action 4:

Upon approval of this document, IANA will make the following changes in
the "Result-Code (AVP Code 7) AVP Values" registry at
http://www.iana.org/assignments/pana-parameters/pana-parameters.xhtml

OLD:

Registration Procedures
IETF Consensus

NEW:

Registration Procedures
IETF Consensus or IESG Approval


Action 5:

Upon approval of this document, IANA will make the following changes in
the "Termination-Cause (AVP Code 9) AVP Values" registry at
http://www.iana.org/assignments/pana-parameters/pana-parameters.xhtml

OLD:

Registration Procedures
IETF Consensus

NEW:

Registration Procedures
IETF Consensus or IESG Approval


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

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

  There is no shepherd. The authors have carefully reviewed the document.

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

  The document has received little review, but it has been reviewed by the
  key participants who feel it is important. We hope that the last call will generate
  additional review; the PANA WG has been closed some months ago, and the list
  is quiet.

  (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. We believe the draft is ready to be published as an RFC. However,
  additional LC reviews are useful.

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

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

  Those who have expressed an interest are clearly behind this
  work.

  (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 the Internet-Drafts Checklist
        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?

  There are no nits, except for using an older version of the boilerplate text.

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

  Yes, no issues.

  (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 Shepherd conferred with the
        Responsible Area Director so that the IESG can appoint the needed
        Expert during the IESG Evaluation?

  The entire document is about IANA considerations.

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

  (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. The approval
        announcement contains the following sections:

    Technical Summary

        This draft updates the IANA considerations for the PANA protocol.

    Working Group Summary

        This draft came about, as another PANA draft needed to allocate a
        number from a space where it was not per the existing RFCs allowed to
        do so.

    Document Quality   

        This draft is purely administrative, there are no implementation
        aspects.