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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 08 February 2012 11:50 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 70AA721F85D2 for <hokey@ietfa.amsl.com>; Wed, 8 Feb 2012 03:50:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.299
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlQnhE6AJzr3 for <hokey@ietfa.amsl.com>; Wed, 8 Feb 2012 03:50:03 -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 EFA0721F85C3 for <hokey@ietf.org>; Wed, 8 Feb 2012 03:50:02 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 60160153C0F; Wed, 8 Feb 2012 11:50:02 +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=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 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 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 smtp.scss.tcd.ie (Postfix) with ESMTPSA id 6BBBE171C2F; Wed, 8 Feb 2012 11:50:01 +0000 (GMT)
Message-ID: <4F326160.5040705@cs.tcd.ie>
Date: Wed, 08 Feb 2012 11:49:52 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
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 <Tina.Tsou.Zouting@huawei.com>
References: <C0E0A32284495243BDE0AC8A066631A80C1FA5E0@szxeml526-mbs.china.huawei.com> <4ECE4447.6040500@cs.tcd.ie> <C0E0A32284495243BDE0AC8A066631A80C1FB925@szxeml526-mbs.china.huawei.com> <4ECE68BF.8080708@cs.tcd.ie>
In-Reply-To: <4ECE68BF.8080708@cs.tcd.ie>
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: 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
review?

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:stephen.farrell@cs.tcd.ie]
>> Sent: Thursday, November 24, 2011 5:19 AM
>> To: Tina TSOU
>> Cc: hokey@ietf.org
>> 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<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
>>>
>>>
>>>
>>>
>>
> _______________________________________________
> HOKEY mailing list
> HOKEY@ietf.org
> https://www.ietf.org/mailman/listinfo/hokey
>