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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 24 November 2011 13:19 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: hokey@ietfa.amsl.com
Delivered-To: hokey@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E0421F8B9F for <hokey@ietfa.amsl.com>; Thu, 24 Nov 2011 05:19:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQjQH+OJHSOA for <hokey@ietfa.amsl.com>; Thu, 24 Nov 2011 05:19:15 -0800 (PST)
Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 0DED721F8B87 for <hokey@ietf.org>; Thu, 24 Nov 2011 05:19:15 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 77A4D171CB7; Thu, 24 Nov 2011 13:19:14 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; 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=1322140753; bh=J2XU6/vt8IhlNV TGBsqzL5f9XQg+DqriC8Hi2i/58R8=; b=pKUSru5PX8Q3GtDJU9IDrKl8TNLZIv zvQuWN96z+Og7Zp4SYIZGGFtck1slrjHZg0xWeTstm1c94lnSbyxXT6+6fnEkyYr e5lho/+Npt3yhLkLT3lHk4SGyoAf6aOKuLFIzTUknazYVwC2LRmDI24Y3EvGk8+c +2ARsMwJrizsA/O/ilCW8SqsGl4XTxMtxXpVVh5kuO11QmTQO9xAuZi0St+yuztB R8hOTxPmYsfoXpnh/OrSS2+/zpeO1Cyf9d+jX9nYqlLceYpCUsAtjLPMzprseYER o7ckzYyokb+abPktlbomTCTIgFmVOk03raLEJSB20bDR2FgK0GxvXW5Q==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id rRFdsOaYqQKW; Thu, 24 Nov 2011 13:19:13 +0000 (GMT)
Received: from [10.87.48.8] (unknown [86.42.16.250]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 9996F171C21; Thu, 24 Nov 2011 13:19:13 +0000 (GMT)
Message-ID: <4ECE4447.6040500@cs.tcd.ie>
Date: Thu, 24 Nov 2011 13:19:03 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
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 <Tina.Tsou.Zouting@huawei.com>
References: <C0E0A32284495243BDE0AC8A066631A80C1FA5E0@szxeml526-mbs.china.huawei.com>
In-Reply-To: <C0E0A32284495243BDE0AC8A066631A80C1FA5E0@szxeml526-mbs.china.huawei.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "hokey@ietf.org" <hokey@ietf.org>
Subject: Re: [HOKEY] PROTO write-up for draft-ietf-hokey-rfc5296bis-06
X-BeenThere: hokey@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: HOKEY WG Mailing List <hokey.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hokey>, <mailto:hokey-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hokey>
List-Post: <mailto:hokey@ietf.org>
List-Help: <mailto:hokey-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hokey>, <mailto:hokey-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Nov 2011 13:19:16 -0000

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<Tina.Tsou.Zouting@huawei.com>
>
>          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
>
>
>
>