Authentication, Authorization, and Accounting (AAA) Goals for Mobile IPv6
draft-ietf-mext-aaa-ha-goals-01

[Ballot comment]
In section 4.2, Integrated Scenario, the acronym AAAH is introduced without any explanation.
It does not appear in RFCs 3775, 4640, or 5026.  It is used but not defined in
mip6-bootstrapping-integrated-dhc.  I finally found it in RFC 4285.  That was painful, and
could have been avoided by either noting that some terms are extracted from [5] in section
2, Terminology, or expanding it on first use.

Nits:

Section 4.1

s/vailidity/validity/

4.2

s/The Home Agent can the assigned/The Home Agent can be assigned/

[Ballot discuss]
Eric Gray posted a Gen-ART Review of during IETF Last Call, but it has
  not received a response.  A new version of the document has not been
  posted since the review.  Eric suggests that the document is "not ready
  for publishing as an Informational RFC."  Please respond to the review.

Document Shepherd Write-up for draft-ietf-mext-aaa-ha-goals-01

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

    The document shepherd is Marcelo Bagnulo.
    I have read the document and i believe is ready for
    forwarding to the IESG 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?
        The document was reviewed by key WG members including
    James Kempf, Alper Yegin, Vijay Devarapalli, Basavaraj
    Patil and Gopal Dommety.
    In addition, since this document is an input from MEXT WG
    to the DIME WG, the document was forwarded for review
    to the DIME WG, where it received an in depth review from
    Hannes Tschofenig.

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

    I don't have any concerns with respect to further reviews.
    I think that the critical review was from the DIME WG
    which was performed already.

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

    I don't have any concerns with the document. I think there
    is a need for this document, as an input to the DIME WG.
    No concerns about advancing this document were expressed in
    the MEXT WG.
    No IPR issues that i am aware of (it should be noted that
    the document is describing goals, so it is unlikely that it
    would present IPR issues)

(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 document has received a sufficient amount of reviews and
    people seem to agree with the need for this 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 expression of discontent have been expressed with the
    document and no-one threatened with an appeal.

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

    The ID nits results in one comment:

      == Unused Reference: '7' is defined on line 414, but no
    explicit reference was found in the text '[7]  Patel, A.,
    Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury,...'

    The document has received all the formal reviews needed
    i.e. none since it is a goals 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 into normative and informative.
      There is a normative reference to
    draft-ietf-mip6-bootstrapping-integrated-dhc-06, which
    status is RFC-edi queue.

    There is an informative reference to
    draft-ietf-mip6-nemo-v4traversal-06 which will be send
    to the IESG for publication as a Standard track RFC shortly.

    Since the document intended status is INFORMATIONAL,
    there is no issues with downward 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?

    The IANA considerations section exists and it is coherent
    with the body of the document (i.e. no IANA action is
    required since it is a goals document).

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

    No sections written in formal language in the document.

(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
          Relevant content can frequently be found in the abstract
          and/or introduction of the document.  If not, this may be
          an indication that there are deficiencies in the abstract
          or introduction.

Mobile IPv6 provides the basic IP mobility functionality for
IPv6.  When Mobile IPv6 is used in tightly managed environments with
the use of the AAA (Authentication, Authorization and Accounting)
infrastructure, an interface between Mobile IPv6 and AAA protocols
needs to be defined.  Also, two scenarios for bootstrapping Mobile
IPv6 service, i.e., split and integrated scenarios,
require the specification of a message exchange between the HA and
AAA infrastructure for authentication and authorization purposes and
a message exchange between the AAA server and the NAS in order to
provide the visited network with the necessary configuration
information (e.g.  Home Agent address).

This document describes various scenarios where a AAA interface is
required.  Additionally, it lists design goals and requirements for
the communication between the HA and the AAA server and the NAS and
the AAA server needed in the split and integrated scenarios.
Requirements are listed in case either IPsec or rfc 4285 [5] is used
for Mobile IPv6 authentication.

This document only describes requirements, goals and scenarios.  It
does not provide solutions.

        Working Group Summary
          Was there anything in the WG process that is worth noting?
          For example, was there controversy about particular points
          or were there decisions where the consensus was
          particularly rough?

          No special issues where encountered during the
      process of the document.

        Document Quality
          Are there existing implementations of the protocol?  Have a
          significant number of vendors indicated their plan to
          implement the specification?  Are there any reviewers that
          merit special mention as having done a thorough review,
          e.g., one that resulted in important changes or a
          conclusion that the document had no substantive issues?  If
          there was a MIB Doctor, Media Type, or other Expert Review,
          what was its course (briefly)?  In the case of a Media Type
          Review, on what date was the request posted?

      The document does not specifies a document but a set
      of goals. As such there is no implementation of it, nor
      plans to implement it. There was however, a strong
      expression of interest in this document from the DIME
      WG which this document is an input to.

      There was a thorough review of the document from Hannes
          Tschofenig.

        Personnel
          Who is the Document Shepherd for this document?  Who is the
          Responsible Area Director?  If the document requires IANA
          experts(s), insert 'The IANA Expert(s) for the registries
          in this document are .'

      The document shepherd is Marcelo Bagnulo.
      The responsible AD is Jari Arkko.