Re: [radext] Publication request for RADIUS attributes for IPv6 Access Networks; draft-ietf-radext-ipv6-access-11
Leaf yeh <leaf.y.yeh@huawei.com> Mon, 13 August 2012 08:46 UTC
Return-Path: <leaf.y.yeh@huawei.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9FAB21F8704 for <radext@ietfa.amsl.com>; Mon, 13 Aug 2012 01:46:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.153
X-Spam-Level:
X-Spam-Status: No, score=-6.153 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 IoMDPgEjsc7U for <radext@ietfa.amsl.com>; Mon, 13 Aug 2012 01:46:50 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id AE29F21F86FC for <radext@ietf.org>; Mon, 13 Aug 2012 01:46:50 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIV01061; Mon, 13 Aug 2012 00:46:50 -0800 (PST)
Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 13 Aug 2012 01:44:26 -0700
Received: from SZXEML437-HUB.china.huawei.com (10.72.61.72) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 13 Aug 2012 01:44:23 -0700
Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.103]) by szxeml437-hub.china.huawei.com ([10.72.61.72]) with mapi id 14.01.0323.003; Mon, 13 Aug 2012 16:44:19 +0800
From: Leaf yeh <leaf.y.yeh@huawei.com>
To: "Wojciech Dec (wdec)" <wdec@cisco.com>, jouni korhonen <jouni.nospam@gmail.com>
Thread-Topic: [radext] Publication request for RADIUS attributes for IPv6 Access Networks; draft-ietf-radext-ipv6-access-11
Thread-Index: AQHNdwdirHPcwySeb0WtUhoAEWQLBJdXahwQ
Date: Mon, 13 Aug 2012 08:44:18 +0000
Message-ID: <E1CE3E6E6D4E1C438B0ADC9FFFA345EA3C4581F9@SZXEML510-MBS.china.huawei.com>
References: <E1CE3E6E6D4E1C438B0ADC9FFFA345EA3C4524E4@SZXEML510-MBS.china.huawei.com> <CC4AE680.1B652%wdec@cisco.com>
In-Reply-To: <CC4AE680.1B652%wdec@cisco.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.66.83.152]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "Benoit Claise (bclaise)" <bclaise@cisco.com>, "radext@ietf.org" <radext@ietf.org>
Subject: Re: [radext] Publication request for RADIUS attributes for IPv6 Access Networks; draft-ietf-radext-ipv6-access-11
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Aug 2012 08:46:52 -0000
Woj - This would be an IPv4 related restriction, that is out of scope for this draft. Not sure I would buy in it, I think it might be a good opportunity to make a clarification here, for the 2 new created 'pool name' attribute with the same data type of string are on the base that we decide not to reuse the attribute 88 named 'Framed-Pool'. Best Regards, Leaf -----Original Message----- From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] Sent: Friday, August 10, 2012 10:50 PM To: Leaf yeh; jouni korhonen Cc: Benoit Claise (bclaise); radext@ietf.org Subject: Re: [radext] Publication request for RADIUS attributes for IPv6 Access Networks; draft-ietf-radext-ipv6-access-11 On 06/08/2012 03:15, "Leaf yeh" <leaf.y.yeh@huawei.com> wrote: ><quote>Technical Summary > > The I-D defines additional attributes for various IPv6 > access network deployments (be that fixes or mobile network). > The attributes complement already existing set of IPv6 attributes > defined in e.g., RFC3162 and RFC4818. Furthermore, the I-D clarifies > the use of some existing IPv6 related attributes and the relationship > of those to the newly defined attributes. </quote> > > >Would the I-D like to clarify one more item as follows: Use of the >Frame-Pool (88) attribute should be restricted to authorization of IPv4 >address pool as per the fact of the internet industry, so this I-D has >not reused it for Stateful-IPv6-Address-Pool or >Delegated-IPv6-Prefix-Pool ? This would be an IPv4 related restriction, that is out of scope for this draft. Regards, Woj.. > > >Best Regards, >Leaf > > >-----Original Message----- >From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf >Of jouni korhonen >Sent: Saturday, August 04, 2012 4:34 AM >To: iesg-secretary@ietf.org >Cc: Benoit Claise; radext@ietf.org >Subject: [radext] Publication request for RADIUS attributes for IPv6 >Access Networks; draft-ietf-radext-ipv6-access-11 > >Dear Secretary, > >This is a request for publication of draft-ietf-radext-ipv6-access-11 as >a standards track RFC. > >- Jouni > >------------------------------------------------------- > >(1) What type of RFC is being requested (BCP, Proposed Standard, >Internet Standard, Informational, Experimental, or Historic)? Why >is this the proper type of RFC? Is this type of RFC indicated in the >title page header? > > RADIUS attributes for IPv6 Access Networks is to be published > as a Standards Track RFC, which is indicated in the I-D's > cover page Intended Status field. > > The RADIUS attributes defined in this I-D are needed for the > emerging IPv6 deployments across multiple types of network > architectures. > >(2) 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 > > The I-D defines additional attributes for various IPv6 > access network deployments (be that fixes or mobile network). > The attributes complement already existing set of IPv6 attributes > defined in e.g., RFC3162 and RFC4818. Furthermore, the I-D clarifies > the use of some existing IPv6 related attributes and the relationship > of those to the newly defined attributes. > > >Working Group Summary > > The I-D has been discussed extensively in the RADEXT WG and has > reached the overall working group consensus. There was a lengthy > discussion regarding the Route-IPv6-Information attribute format > and whether it should also contain the rest of the RFC4191 Route > Information Option field in addition to the prefix. The WG > reached a consensus that the other values are local to router > configuration and not retrieved from the RADIUS server. > >Document Quality > > There is specific interest from the Broadband Forum to incorporate > the attributes defined in this specification into their respective > IPv6 standards. > > AAA Doctors have not reviewed the document yet. There is no need > for MIB or other doctorate review. > > Once the document goes to IETF LC, a review from V6OPS should be > requested. > >Personnel > > Who is the Document Shepherd? Who is the Responsible Area > Director? > > Jouni Korhonen (jouni.nospam@gmail.com) is the document > shepherd. > >(3) Briefly describe the review of this document that was performed by >the Document Shepherd. If this version of the document is not ready >for publication, please explain why the document is being forwarded to >the IESG. > > The document shepherd has reviewed the document after it has > concluded the WGLC. The document shepherd thinks the document > is ready for publication and there is no reason to delay the > publication anymore, since the attributes defined in this > document are needed by the industry. > >(4) Does the document Shepherd have any concerns about the depth or >breadth of the reviews that have been performed? > > No. > >(5) Do portions of the document need review from a particular or from >broader perspective, e.g., security, operational complexity, AAA, DNS, >DHCP, XML, or internationalization? If so, describe the review that >took place. > > The document should be reviewed by V6OPS once it goes to > IETF LC. > >(6) Describe any specific concerns or issues that the Document Shepherd >has 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. > > The document shepherd has no specific concerns. > >(7) Has each author confirmed that any and all appropriate IPR >disclosures required for full conformance with the provisions of BCP 78 >and BCP 79 have already been filed. If not, explain why. > > No IPRs have been declared. > >(8) Has an IPR disclosure been filed that references this document? >If so, summarize any WG discussion and conclusion regarding the IPR >disclosures. > > No IPRs have been declared. > >(9) 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? > > The WG consensus is solid and does not represent only the > opinion of few individuals. > >(10) Has anyone threatened an appeal or otherwise indicated extreme >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 publicly available.) > > No. > >(11) Identify any ID nits the Document Shepherd has found in this >document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts >Checklist). Boilerplate checks are not enough; this check needs to be >thorough. > > The document passes IDnits. > >(12) Describe how the document meets any required formal review >criteria, such as the MIB Doctor, media type, and URI type reviews. > > The document does not define MIBs, media types, URIs etc. > The data types used in the document comply with RFC6158. > >(13) Have all references within this document been identified as >either normative or informative? > > Yes. > >(14) 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 plan for their completion? > > No. > >(15) Are there downward normative references references (see RFC 3967)? >If so, list these downward references to support the Area Director in the >Last Call procedure. > > No. > >(16) Will publication of this document change the status of any >existing RFCs? Are those RFCs listed on the title page header, listed >in the abstract, and discussed in the introduction? If the RFCs are not >listed in the Abstract and Introduction, explain why, and point to the >part of the document where the relationship of this document to the >other RFCs is discussed. If this information is not in the document, >explain why the WG considers it unnecessary. > > No. > >(17) Describe the Document Shepherd's review of the IANA considerations >section, especially with regard to its consistency with the body of the >document. Confirm that all protocol extensions that the document makes >are associated with the appropriate reservations in IANA registries. >Confirm that any referenced IANA registries have been clearly >identified. Confirm that newly created IANA registries include a >detailed specification of the initial contents for the registry, that >allocations procedures for future registrations are defined, and a >reasonable name for the new registry has been suggested (see RFC 5226). > > The document only requests for five new RADIUS attribute types > from an existing IANA registry. > >(18) List any new IANA registries that require Expert Review for future >allocations. Provide any public guidance that the IESG would find >useful in selecting the IANA Experts for these new registries. > > None. > >(19) Describe reviews and automated checks performed by the Document >Shepherd to validate sections of the document written in a formal >language, such as XML code, BNF rules, MIB definitions, etc. > > Checked with IDnits and verified against RFC6158 RADIUS > design guidelines. > >_______________________________________________ >radext mailing list >radext@ietf.org >https://www.ietf.org/mailman/listinfo/radext >_______________________________________________ >radext mailing list >radext@ietf.org >https://www.ietf.org/mailman/listinfo/radext
- [radext] Publication request for RADIUS attribute… jouni korhonen
- Re: [radext] Publication request for RADIUS attri… Leaf yeh
- Re: [radext] Publication request for RADIUS attri… Leaf yeh
- Re: [radext] Publication request for RADIUS attri… Leaf yeh
- Re: [radext] Publication request for RADIUS attri… Wojciech Dec (wdec)
- Re: [radext] Publication request for RADIUS attri… Wojciech Dec (wdec)
- Re: [radext] Publication request for RADIUS attri… Leaf yeh
- Re: [radext] Publication request for RADIUS attri… Leaf yeh
- Re: [radext] Publication request for RADIUS attri… jouni korhonen
- Re: [radext] Publication request for RADIUS attri… Leaf yeh
- Re: [radext] [MARKETING] Re: Publication request … Wojciech Dec (wdec)
- Re: [radext] [MARKETING] Re: Publication request … Leaf yeh
- Re: [radext] [MARKETING] Re: Publication request … Maglione Roberta
- Re: [radext] [MARKETING] Re: Publication request … Leaf yeh