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

[Tina TSOU <[e-mail]>]

Tina


> -----Original Message-----
> From: Stephen Farrell [mailto:[e-mail]]
> Sent: Wednesday, February 08, 2012 3:50 AM
> To: Tina TSOU
> Cc: [e-mail]
> Subject: Re: [HOKEY] PROTO write-up for draft-ietf-hokey-rfc5296bis-06
> 
> 
> 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?
I think there are no substantive changes to be made for now.
> 
> 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:[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
> >>>
> >>>
> >>>
> >>>
> >>
> > _______________________________________________
> > HOKEY mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/hokey
> >