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

Tina TSOU <Tina.Tsou.Zouting@huawei.com> Thu, 09 February 2012 01:03 UTC

Return-Path: <Tina.Tsou.Zouting@huawei.com>
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 74CCB11E8075 for <hokey@ietfa.amsl.com>; Wed, 8 Feb 2012 17:03:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.457
X-Spam-Level:
X-Spam-Status: No, score=-6.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 vd5rZbyV7WqL for <hokey@ietfa.amsl.com>; Wed, 8 Feb 2012 17:03:21 -0800 (PST)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 03FCB11E8072 for <hokey@ietf.org>; Wed, 8 Feb 2012 17:03:21 -0800 (PST)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ300E3IPL89S@szxga05-in.huawei.com> for hokey@ietf.org; Thu, 09 Feb 2012 09:03:08 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ300AMCPL7CS@szxga05-in.huawei.com> for hokey@ietf.org; Thu, 09 Feb 2012 09:03:08 +0800 (CST)
Received: from szxeml211-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGY78668; Thu, 09 Feb 2012 09:02:59 +0800
Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml211-edg.china.huawei.com (172.24.2.182) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 09 Feb 2012 09:02:17 +0800
Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.225]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0323.003; Thu, 09 Feb 2012 09:02:39 +0800
Date: Thu, 09 Feb 2012 01:02:38 +0000
From: Tina TSOU <Tina.Tsou.Zouting@huawei.com>
In-reply-to: <4F326160.5040705@cs.tcd.ie>
X-Originating-IP: [10.193.34.156]
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Message-id: <C0E0A32284495243BDE0AC8A066631A80C29C64A@szxeml526-mbs.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: en-US
Content-transfer-encoding: 7BIT
Accept-Language: en-US, zh-CN
Thread-topic: [HOKEY] PROTO write-up for draft-ietf-hokey-rfc5296bis-06
Thread-index: AQHM5lfWEt3oFeKmx0mMi6noRczRK5YzwAVw
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-CFilter-Loop: Reflected
References: <C0E0A32284495243BDE0AC8A066631A80C1FA5E0@szxeml526-mbs.china.huawei.com> <4ECE4447.6040500@cs.tcd.ie> <C0E0A32284495243BDE0AC8A066631A80C1FB925@szxeml526-mbs.china.huawei.com> <4ECE68BF.8080708@cs.tcd.ie> <4F326160.5040705@cs.tcd.ie>
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, 09 Feb 2012 01:03:22 -0000

Tina


> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
> Sent: Wednesday, February 08, 2012 3:50 AM
> To: Tina TSOU
> Cc: hokey@ietf.org
> Subject: Re: [HOKEY] PROTO write-up for draft-ietf-hokey-rfc5296bis-06
> 
> 
> 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?
I think there are no substantive changes to be made for now.
> 
> 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
> >