Re: [radext] [MARKETING] Re: Publication request for RADIUS attributes for IPv6 Access Networks; draft-ietf-radext-ipv6-access-11
"Wojciech Dec (wdec)" <wdec@cisco.com> Tue, 14 August 2012 09:15 UTC
Return-Path: <wdec@cisco.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 32EA621F8599 for <radext@ietfa.amsl.com>; Tue, 14 Aug 2012 02:15:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.699
X-Spam-Level:
X-Spam-Status: No, score=-109.699 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, 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 0uT57FV5M8gw for <radext@ietfa.amsl.com>; Tue, 14 Aug 2012 02:15:17 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id A4A2C21F8594 for <radext@ietf.org>; Tue, 14 Aug 2012 02:15:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=11300; q=dns/txt; s=iport; t=1344935717; x=1346145317; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=1cxGl1pRuE81KANpKSPflTYN8dNJQODRaf0i8ZWKRdA=; b=MEZAktiWb2NuQItx/PYDl4OpZAtb5uveHm/jxfohCpLElHTIVWhnlzYG bGinl5LVTnHY1W6JAJt4IR7BYwmox7l2g0tveMh17D+nMft6n6I7lbeMC aWd3BRGyWaNyCggzIRas7FOuTzbOd0lEj27hPmM55m4lyxJe/CXIQ2aD0 g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAL0WKlCtJV2a/2dsb2JhbAA6CroOgQeCIAEBAQQBAQEPAScxAwEDBwwGAQgRBAEBAR4FBCgGCxQJCAIEAQ0FCRmHXAMMC5gYlywNiU6KIWQQCoYXA5N4gVOBFIl2gyCBZoJfgVgHHA
X-IronPort-AV: E=Sophos;i="4.77,765,1336348800"; d="scan'208";a="111338823"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 14 Aug 2012 09:15:17 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q7E9FGpG011170 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Aug 2012 09:15:16 GMT
Received: from xmb-aln-x05.cisco.com ([169.254.11.223]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0298.004; Tue, 14 Aug 2012 04:15:16 -0500
From: "Wojciech Dec (wdec)" <wdec@cisco.com>
To: Leaf yeh <leaf.y.yeh@huawei.com>, jouni korhonen <jouni.nospam@gmail.com>
Thread-Topic: [MARKETING] Re: [radext] Publication request for RADIUS attributes for IPv6 Access Networks; draft-ietf-radext-ipv6-access-11
Thread-Index: AQHNdwdcGGwam+2DOkqGQSV+ZztgDZdXxWkAgAG8f4A=
Date: Tue, 14 Aug 2012 09:15:15 +0000
Message-ID: <CC4FE267.1BAEB%wdec@cisco.com>
In-Reply-To: <E1CE3E6E6D4E1C438B0ADC9FFFA345EA3C4581F9@SZXEML510-MBS.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.55.91.149]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19112.003
x-tm-as-result: No--68.906600-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-ID: <FEB5D8D340C37E4593BDD01F7DD523AB@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Benoit Claise (bclaise)" <bclaise@cisco.com>, "radext@ietf.org" <radext@ietf.org>
Subject: Re: [radext] [MARKETING] Re: 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: Tue, 14 Aug 2012 09:15:19 -0000
Leaf, On 13/08/2012 10:44, "Leaf yeh" <leaf.y.yeh@huawei.com> wrote: >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'. It appears that we have discussed this topic before in the context of the re-use of other pool attributes. The issue remains the same IMO, and given that the framed-pool-name attribute is an attribute which this draft does not scope, and which deals with IPv4, until advised otherwise I'll stick to the consensus previously established: http://tools.ietf.org/wg/radext/minutes?item=minutes82.html http://www.ietf.org/mail-archive/web/radext/current/msg02318.html Regards, Woj.. > > >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 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