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

Stephen Farrell <> Wed, 08 February 2012 11:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 70AA721F85D2 for <>; Wed, 8 Feb 2012 03:50:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.299
X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YlQnhE6AJzr3 for <>; Wed, 8 Feb 2012 03:50:03 -0800 (PST)
Received: from ( [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by (Postfix) with ESMTP id EFA0721F85C3 for <>; Wed, 8 Feb 2012 03:50:02 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 60160153C0F; Wed, 8 Feb 2012 11:50:02 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1328701801; bh=Est6WjCS8nb1sY xKES+m/oCSGOTlN7710pBvsN82weo=; b=JKocsY5dvtynU4Pes5DOSH5FN0ptK4 NgCbkym33pmr6YXu5vasGMae5guTbMUKDmRetdpgRzF5uTSiQ3tH0BJcY/pP9y+I sSSHBmtf7+bU7/fo7TGQSrhmWbqRlo8A7yw6GEHaIeOltC03hzRQRp185iACzHdV 8GvD9SNhNtdF34/StHH/h5X0JIAziyOWzYw4+8m+Fzcw5faYZNDxQbDuKWWIttLy +3mS2/pbLSBwSoVic9G6aleEFdbDzHgwfnrF4HtSDXWC9wwIRurmz4aUsnwB2H+M iIZLvqu8pQQpAexiCU/SPc+pZRHm5P5HJ0+4B6I1uXCNgK7pXgcS5Fag==
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10027) with ESMTP id Fm7En92jp8sy; Wed, 8 Feb 2012 11:50:01 +0000 (GMT)
Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by (Postfix) with ESMTPSA id 6BBBE171C2F; Wed, 8 Feb 2012 11:50:01 +0000 (GMT)
Message-ID: <>
Date: Wed, 08 Feb 2012 11:49:52 +0000
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Tina TSOU <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" <>
Subject: Re: [HOKEY] PROTO write-up for draft-ietf-hokey-rfc5296bis-06
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: HOKEY WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 Feb 2012 11:50:05 -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

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


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 []
>> Sent: Thursday, November 24, 2011 5:19 AM
>> To: Tina TSOU
>> Cc:
>> 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<>
>>> 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
> _______________________________________________
> HOKEY mailing list