[HOKEY] PROTO write-up for draft-ietf-hokey-rfc5296bis-06

[Tina TSOU <[e-mail]>]

Hi Stephen,
Here is the PROTO write-up for draft-ietf-hokey-rfc5296bis-06.

  (1.a) Who is the Document Shepherd for this document?

        Tina Tsou <[e-mail]>

        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?

        Yes and yes.

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

        Yes and no; as the filename indicates this is just a revision
        of RFC 5296, mostly clearing the existing errata, cleaning up
        the language a bit, etc.  No major technical changes were made.

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

        No.

        Has an IPR disclosure related to this document
        been filed?

        No.

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

        Consensus is as strong as for any hokey document.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?

        No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits?

        Yes; idnits generates several spurious warnings caused by
        interpreting elements of a figure as references and one
        down-reference error (see below).

        Has the document met all formal review criteria it needs to,
        such as the MIB Doctor, media type and URI type reviews?

        Yes.

  (1.h) Has the document split its references into normative and
        informative?

	No.

        Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state?

	No.

	Are there normative references
        that are downward references, as described in [RFC3967]?

	Yes.

	If so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].
	
	Split as required. No down-references.

	
  (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?
	
	The IANA considerations section exists; the registry is identified and 
	there are no other new registries.

  (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 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.
	
	The Extensible Authentication Protocol (EAP) is a generic framework
   	supporting multiple types of authentication methods.  In systems
   	where EAP is used for authentication, it is desirable to avoid
   	repeating the entire EAP exchange with another authenticator.  This
   	document specifies extensions to EAP and the EAP keying hierarchy to
   	support an EAP method-independent protocol for efficient re-
   	authentication between the peer and an EAP re-authentication server
   	through any authenticator.  The re-authentication server may be in
   	the home network or in the local network to which the peer is
   	connecting.

	This memo obsoletes RFC 5296.

     Working Group Summary
        Was there anything in WG process that is worth noting? For
        example, was there controversy about particular points or
        were there decisions where the consensus was particularly
        rough?
        
	The document is a product of the Hokey working group. The document has 
        working group consensus.


     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 simplifies the usage scenarios identified and optimizes the procedure, protocol for the specific usage scenario. This document has gotten sufficient review from people with both OPS and Security background. The quality of the document is good.




Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html