Re: [radext] [MARKETING] Re: Publication request for RADIUS attributes for IPv6 Access Networks; draft-ietf-radext-ipv6-access-11

Leaf yeh <leaf.y.yeh@huawei.com> Tue, 14 August 2012 10:28 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 369B521F85D9 for <radext@ietfa.amsl.com>; Tue, 14 Aug 2012 03:28:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.144
X-Spam-Level:
X-Spam-Status: No, score=-6.144 tagged_above=-999 required=5 tests=[AWL=-0.145, 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 00hx8lJgdKyT for <radext@ietfa.amsl.com>; Tue, 14 Aug 2012 03:28:44 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id CD31221F859B for <radext@ietf.org>; Tue, 14 Aug 2012 03:28:43 -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 AIV98305; Tue, 14 Aug 2012 02:28:43 -0800 (PST)
Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 14 Aug 2012 03:25:39 -0700
Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 14 Aug 2012 03:25:41 -0700
Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.103]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Tue, 14 Aug 2012 18:25:36 +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] [MARKETING] Re: Publication request for RADIUS attributes for IPv6 Access Networks; draft-ietf-radext-ipv6-access-11
Thread-Index: AQHNef1sunU7Ra56UkGA1P8JMpDEn5dZB7Lw
Date: Tue, 14 Aug 2012 10:25:35 +0000
Message-ID: <E1CE3E6E6D4E1C438B0ADC9FFFA345EA3C458BAB@SZXEML510-MBS.china.huawei.com>
References: <E1CE3E6E6D4E1C438B0ADC9FFFA345EA3C4581F9@SZXEML510-MBS.china.huawei.com> <CC4FE267.1BAEB%wdec@cisco.com>
In-Reply-To: <CC4FE267.1BAEB%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] [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 10:28:45 -0000

Leaf - 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'.

Woj. - ... until advised otherwise I'll stick
to the consensus previously established:


Then we could only rely on the records in the list archive to let people know that Framed-Pool (88) is dedicated for IPv4. I suppose we never disclose this point before.


http://www.ietf.org/mail-archive/web/radext/current/msg02318.html 
Nelson - > I have no problem with string encodings of pool names.   Since pools
> can be named arbitrarily by the NAS system administrator, anything
> other than a string encoding would be unnatural.  My issue is when we
> try to mix in a fixed set of address assignment methods with the pool
> names.  Separation of concerns.
Woj. - some folks claimed that the proposal in the draft is not needed and that
solving the case by overloading pool naming is better, followed on by a
second proposal for the enumerated type.


I suppose you might talk about the 'Access-Type' proposed in draft-yeh-radext-ext-dual-stack-access (active).


Nelson - > I don't think that specific values for *combinations* of options is a
> good way to go.
Woj. - It's rather clear that an enumerated attribute cannot handle this case.


For example, the user on the NAS get the access type of 'PPPoE-dual-stack-CE (IPv6-Numbered by DHCPv6)', you need include 3 attributes of 'Framed-Pool' (88), 'Delegated-IPv6-Prefix-Pool' and 'Stateful-IPv6-Address-Pool' in the Access-Accept for the assignment of the CE's WAN-interface IPv4 address, the DHCPv6-PD prefix for customer network, and CE's WAN-interface IPv6 address, if all these pools are configured on the NAS. But draft-yeh-radext-ext-dual-stack-access only need one attribute named 'Access-Type '.

The other advantage is the NAS can build the context for users based on their 'Access-Type'. It means we can use 'Access-Type' attribute to indicate the default configuration for users on the NAS.


Best Regards,
Leaf



-----Original Message-----
From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Wojciech Dec (wdec)
Sent: Tuesday, August 14, 2012 5:15 PM
To: Leaf yeh; jouni korhonen
Cc: Benoit Claise (bclaise); radext@ietf.org
Subject: Re: [radext] [MARKETING] Re: Publication request for RADIUS attributes for IPv6 Access Networks; draft-ietf-radext-ipv6-access-11

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 mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext