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

Stephen Farrell <> Thu, 24 November 2011 15:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6167421F8B71 for <>; Thu, 24 Nov 2011 07:54:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FOO3ZfbhwwWp for <>; Thu, 24 Nov 2011 07:54:51 -0800 (PST)
Received: from ( [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by (Postfix) with ESMTP id 253A921F8B64 for <>; Thu, 24 Nov 2011 07:54:50 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3F889171D65; Thu, 24 Nov 2011 15:54:50 +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=1322150089; bh=YHO9r6XqYMKhEm iYMGxf/Sho/7QOwKGXHmcNFgr8ZrM=; b=Nik0+HsMsHGibBhLurJ03kU2MQiVbz Bo0aFRTChMXYq3DPo+E1qh0YxfdgPkIrgEwfljR0kjuVgfCByiCCnYNSsXxUiFj2 3QM2KzLtBP5fFVTZ7eRD4pEGGrwp47tOHV03aJJvQ+8aWbYR+Xc6o4EbNBzzyFZD zkBD86d5zThQEMzeuaE5TipXCl+iPWxpXKix+uev0OU5iVJQkoa+qGJjUxG1W7sS UF8e3O2A4htjZd7sjfDubmaWfxDzcmQ4X7WugymltLu7hle2vJ1a+hhBaxI0OQFH LJjrGvxxVR5y6qB2V665YOuMmUss/7w5tSb1UM/AFxebtW3uBws+JWRQ==
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10027) with ESMTP id tqdsUBphDsCd; Thu, 24 Nov 2011 15:54:49 +0000 (GMT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 8455C171CB7; Thu, 24 Nov 2011 15:54:49 +0000 (GMT)
Message-ID: <>
Date: Thu, 24 Nov 2011 15:54:39 +0000
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20111105 Thunderbird/8.0
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: Thu, 24 Nov 2011 15:54:52 -0000


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


> Happy Thanksgiving!

Not really a holiday here, but thanks,

> 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