Re: [HOKEY] Proto write-up for draft-ietf-hokey-erp-aak

Stephen Farrell <> Wed, 02 November 2011 00:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3DEDC1F0C98 for <>; Tue, 1 Nov 2011 17:09:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.583
X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4IH928PyL1qp for <>; Tue, 1 Nov 2011 17:08:54 -0700 (PDT)
Received: from ( [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by (Postfix) with ESMTP id 7C7E31F0C55 for <>; Tue, 1 Nov 2011 17:08:52 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 86264171C1A; Wed, 2 Nov 2011 00:08:51 +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=1320192531; bh=exTnL0pNQFcSsh ywNci69w9lt+QRD97ELxnfnnf03I4=; b=myrq8Omb6i0Uzq0JRK11YDCh3bQYYc O3/GIB0zPAn/+beI+honcNjz3GYMrhTbYitM3BlqmSOXMH0/5feABf7xnAjhd2SV Q2sD2JooC5abv4hQ/XRzNxxGQEBXPrAltFwoLX+DVtdmLsoKp70zy5bP7bWEjV6G 8xcFNQppdytp/B3z8I7JZy91Qrx2vMwgxy0Bk0/eFnbKiUkcuHpFYsf4wmI6HxuB 1VbiRLjbV6uBYdDXXRbaO1m3/DNfxSSzdxKH49WMb/IUlq+Vf1ylWc++iRiyoosd lN7LSSwCpgI69Mnu6gfxmEfp/PCqKtU6oMmDNwN6+qFPyqLZ8XOecymA==
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10027) with ESMTP id i40g4q9TfnRm; Wed, 2 Nov 2011 00:08:51 +0000 (GMT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id D3DC7171C4C; Wed, 2 Nov 2011 00:08:50 +0000 (GMT)
Message-ID: <>
Date: Wed, 02 Nov 2011 00:08:40 +0000
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.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-erp-aak
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, 02 Nov 2011 00:09:00 -0000

Thanks Tina,

I'll get back in a few days,


On 11/01/2011 11:50 PM, Tina TSOU wrote:
> Hi Stephen,
> Here is the proto write-up for draft-ietf-hokey-erp-aak.
>   (1.a) Who is the Document Shepherd for this document? 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?
> The document shepherd for draft-ietf-hokey-erp-aak is Tina Tsou<>om>.
> I believe this document is ready for forwarding to the IESG for publication.
>         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, the review has been adequate. Both the OPS and security people active in the WG has reviewed it.
>   (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 concerns.
>    (1.d) Do have any specific concerns or
>         issues with this document that the Responsible Area Director
>         and/or the IESG should be aware of? For example, perhaps he
>         or she is uncomfortable with certain parts of the document, or
>         has concerns whether there really is a need for it. In any
>         event, if the WG has discussed those issues and has indicated
>         that it still wishes to advance the document, detail those
>         concerns here. Has an IPR disclosure related to this document
>         been filed? If so, please include a reference to the
>         disclosure and summarize the WG discussion and conclusion on
>      &n s issue.
> IPR disclosure to this document has been brought to the attention of the working group and is purely for defensive use. There are no other concerns.
>   (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?
> It represents the concurrence of a few individuals with others being silent.
>   (1.f) Has anyone threatened an appeal or otherwise indicated extreme
>   &n bsp;&nbs ;discontent? If so, please summarise the areas of conflict in
>         separate email messages to the Responsible Area Director. (It
>         should be in a separate email because this questionnaire is
>         entered into the ID Tracker.)
> No.
>   (1.g) Has the Document Shepherd personally verified that the
>         document satisfies all ID nits? (See the Internet-Drafts Checklist
>         and Boilerplate checks are
>         not enough; this check needs to be thorough. Has the document
>         met all formal review criteria it needs to, such as the MIB
>         Doctor, media type and URI tye review
> Datatracker finds no issues. Idnits is satisfied.
>   (1.h) Has the document split its references into normative and
>         informative? Are there normative references to documents that
>         are not ready for advancement or are otherwise in an unclear
>         state? If such normative references exist, what is the
>         strategy for their completion? Are there normative references
>         that are downward references, as described in [RFC3967]? 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 p;
>     Technical Summary
>     The Extensible Authentication Protocol (EAP) is a generic framework
>     supporting multiple types of authentication methods.
>     The EAP Re-authentication Protocol (ERP) 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.
>     Authenticated Anticipatory Keying (AAK) is a method by which
>     cryptographic keying material may be established upon one or more
>     candidate attachment points (CAPs) prior to handover.  AAK uses the
>     AAA infrastructure for key transport.
>     This document specifies the extensions necessary to enable AAK
>     support in ERP.
>      Working Group Summary
>         The document is a product of the Hokey working group. The document has
>        working group consensus.
>      Document Quality
> The document develops a series of procedure, protocol for the specific usage scenario identified.
> 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