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

From: Stephen Farrell <[email-masked]>
Date: Wed, 08 Feb 2012 11:49:52 +0000

Hi Tina,

I guess its time for me to do the AD review
of this and then on to IETF LC. Any there any
substantive changes to be made before I do my
review?

There are a few references that need updating
but that can be done after AD review.

Thanks,
S.

On 11/24/2011 03:54 PM, Stephen Farrell wrote:
>
> 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:[email-masked]]
>> Sent: Thursday, November 24, 2011 5:19 AM
>> To: Tina TSOU
>> Cc: [email-masked]
>> 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<[email-masked]>
>>>
>>> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hokey
>

---

From: Tina TSOU <[email-masked]>
Date: Thu, 09 Feb 2012 01:02:38 +0000

Tina

> Sent: Wednesday, February 08, 2012 3:50 AM
> To: Tina TSOU
> Cc: [email-masked]
> Subject: Re: [HOKEY] PROTO write-up for draft-ietf-hokey-rfc5296bis-06
> 
> 
> Hi Tina,
> 
I think there are no substantive changes to be made for now.