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

[Stephen Farrell <[e-mail]>]

Hiya,

On 11/24/2011 03:46 PM, Tina TSOU wrote:
> Stephen,
> Agreed with this ordering.

Great.

> Happy Thanksgiving!

Not really a holiday here, but thanks,
S

>
> Best Regards,
> Tina TSOU
>
>
> -----Original Message-----
> From: Stephen Farrell [mailto:[e-mail]]
> Sent: Thursday, November 24, 2011 5:19 AM
> To: Tina TSOU
> Cc: [e-mail]
> Subject: Re: PROTO write-up for draft-ietf-hokey-rfc5296bis-06
>
>
> Thanks Tina,
>
> I guess I'll queue this one up until we get the IETF LC started
> on aak, but if you'd prefer some other ordering let me know,
>
> Thanks,
> S.
>
> PS: Congratulations on getting your final WG document to this
> stage!
>
> On 11/24/2011 04:51 AM, Tina TSOU wrote:
>> 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
>>
>>
>>
>>
>