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

[[e-mail]]

Hi, 

I know this document is not solicting comment at this stage and I am not a 
key WG member of HOKEY either,

but I'd like to put forward a little suggestion or a question:
Could the definition of "ERP bootstrapping" be explictly included in it? 
It will make the reading more clearer. 


Regards~~~

-Sujing Zhou

[e-mail] 写于 2011-11-24 12:51:09:

> 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
> 
> 
> 
> _______________________________________________
> HOKEY mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hokey
> 



--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.