Re: [HOKEY] Proto write-up for draft-ietf-hokey-erp-aak

[Stephen Farrell <[e-mail]>]

Thanks Tina,

I'll get back in a few days,

S.

On 11/01/2011 11:50 PM, Tina TSOU wrote:
> Hi Stephen,
> Here is the proto write-up for draft-ietf-hokey-erp-aak.
>
>
>   (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 for draft-ietf-hokey-erp-aak is Tina Tsou<[e-mail]>.
> I believe this document is ready for forwarding to the IESG for publication.
>
>
>         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, the review has been adequate. Both the OPS and security people active in the WG has reviewed it.
>
>
>   (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 concerns.
>
>    (1.d) Do 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
>      &n s issue.
>
> IPR disclosure to this document has been brought to the attention of the working group and is purely for defensive use. There are no other concerns.
>
>
>   (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?
>
> It represents the concurrence of a few individuals with others being silent.
>
>   (1.f) Has anyone threatened an appeal or otherwise indicated extreme
>   &n bsp;&nbs ;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 tye review
>
> Datatracker finds no issues. Idnits is satisfied.
>
>   (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].
>
> 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 p;
>
>     Technical Summary
>
>     The Extensible Authentication Protocol (EAP) is a generic framework
>     supporting multiple types of authentication methods.
>
>     The EAP Re-authentication Protocol (ERP) 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.
>
>     Authenticated Anticipatory Keying (AAK) is a method by which
>     cryptographic keying material may be established upon one or more
>     candidate attachment points (CAPs) prior to handover.  AAK uses the
>     AAA infrastructure for key transport.
>
>     This document specifies the extensions necessary to enable AAK
>     support in ERP.
>
>
>
>      Working Group Summary
>         The document is a product of the Hokey working group. The document has
>        working group consensus.
>
>
>      Document Quality
>
>
> The document develops a series of procedure, protocol for the specific usage scenario identified.
> 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
>
>
>
>