Shepherd writeup

The Netext WG I-D: "RADIUS Support for Proxy Mobile IPv6",
<draft-ietf-netext-radius-pmip6-05> has completed working group last
call and is ready to be progressed for IESG review and approval.

The I-D is a standards track document. The proto writeup for this I-D
is below.


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

I (Basavaraj Patil) am the document shepherd for this I-D. I have
reviewed this version of the document and believe that it is ready to
be forwarded 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 has been reviewed by RADIUS experts as well as a few key WG
members. It has been reviewed adequately. I do not have any concerns
about the depth or breadth of the reviews w.r.t this I-D.

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

The document has been reviewed by RADIUS experts. There is also some
implementation experience of the specification. Hence additional
reviews from a specific group or broader community is not
essential. However a review by the Ops area directorate on the various
RADIUS attributes being specified would be 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 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 do not have any specific concerns with the document. The I-D
specifies several new attributes (RADIUS) which are summarized in Sec
5.2 and the AD may want to pay attention to it. There have been no IPR
disclosures related to this I-D.

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

There is strong WG consensus behind this document. It is essential for
enabling the deployment of PMIP6 (RFC5213) protocol. The WG as a whole
does understand the relevance of this I-D and agrees with it.

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


(1.g) Has the Document Shepherd personally verified that the 
        document satisfies all ID nits? (See the Internet-Drafts Checklist 
        and 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?   

Yes. I have run the I-D throigh the tool and it has passed.

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

The document has split references into normative and informative
ones. All normative references are RFCs.
(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 suggest a 
        reasonable name for the new registry? See [RFC5226]. 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?   

Yes, the I-D does include an IANA considerations section which lists
the set of attributes that need IANA action. The document does not
recommend any new registry to be created. New RADIUS attributes (PMIP6
specific) are specified by this I-D and IANA assignments handled

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

I-D does not contain any XML code, BNF rules or MIB definitions.

(1.k) The IESG approval announcement includes a Document 
        Announcement Write-Up. Please provide such a Document 
        Announcement Write-Up? 

Technical summary:
   This document defines new attributes to facilitate Proxy Mobile IPv6
   operations using the RADIUS infrastructure.  The protocol specified
   here uses RADIUS based interfaces of the mobile access
   gateway and the local mobility anchor with the AAA server for
   authentication, authorization and policy functions.  The RADIUS
   interactions between the mobile access gateway and the RADIUS-based
   AAA server take place when the Mobile Node attaches to the network,
   authenticates and authorizes within a Proxy Mobile IPv6 domain.
   Furthermore, this document defines the RADIUS-based interface
   between the local mobility anchor and the AAA RADIUS server for
   authorizing received Proxy Binding Update messages for the mobile
   node's mobility session.    
   Additionally, this document specifies the baseline for the mobile
   access gateway and the local mobility anchor generated accounting.

Working group summary:
    The document has been reviewed by several RADIUS protocol experts
    as well as key members within the working group. It has undergone
    two working group last calls and has been revised based on
    feedback from reviewers as well as implementation experience.
    There is strong WG consensus behind this document.

Document quality:
    There is at least one known implementation of the
    protocol. Multiple vendors have indicated plans to implement this
    All the key people who have reviewed this I-D are acknowledged in
    the document.