Re: [radext] [MARKETING] Re: AD review: draft-ietf-radext-ipv6-access-11
Benoit Claise <bclaise@cisco.com> Tue, 11 September 2012 13:41 UTC
Return-Path: <bclaise@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 E9C7D21F87E2 for <radext@ietfa.amsl.com>; Tue, 11 Sep 2012 06:41:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.912
X-Spam-Level:
X-Spam-Status: No, score=-4.912 tagged_above=-999 required=5 tests=[AWL=-2.313, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfggTuVzcZJc for <radext@ietfa.amsl.com>; Tue, 11 Sep 2012 06:41:56 -0700 (PDT)
Received: from av-tac-bru.cisco.com (spooky-brew.cisco.com [144.254.15.113]) by ietfa.amsl.com (Postfix) with ESMTP id C77CB21F87C8 for <radext@ietf.org>; Tue, 11 Sep 2012 06:41:55 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8BDfj8I018975; Tue, 11 Sep 2012 15:41:45 +0200 (CEST)
Received: from [10.60.67.93] (ams-bclaise-89112.cisco.com [10.60.67.93]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8BDfjOq008934; Tue, 11 Sep 2012 15:41:45 +0200 (CEST)
Message-ID: <504F3F99.3030603@cisco.com>
Date: Tue, 11 Sep 2012 15:41:45 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0
MIME-Version: 1.0
To: Leaf yeh <leaf.y.yeh@huawei.com>
References: <502522E8.1080700@cisco.com> <E1CE3E6E6D4E1C438B0ADC9FFFA345EA3C4581BD@SZXEML510-MBS.china.huawei.com>
In-Reply-To: <E1CE3E6E6D4E1C438B0ADC9FFFA345EA3C4581BD@SZXEML510-MBS.china.huawei.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "radext@ietf.org" <radext@ietf.org>, "draft-ietf-radext-ipv6-access@tools.ietf.org" <draft-ietf-radext-ipv6-access@tools.ietf.org>
Subject: Re: [radext] [MARKETING] Re: AD review: 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, 11 Sep 2012 13:41:57 -0000
Leah, Thanks for your answer. Regards, B. > Benoit - Recursive DNS Servers. Why recursive? > > We can also find option 23 named 'DNS Recursive Name Server Option' for DHCPv6 (http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml ). I guess 'recursive' might be a native feature of DNS. > > > Benoit - where does the "framed" in the attribute naming convention come from? > > I guess the 1st 'framed' might appear in the attribute 6 named 'Service-Type' defined in RADIUS basic protocol, section 5.6 of RFC2865 (http://www.iana.org/assignments/radius-types/radius-types.xml ). > > <quote> Framed A Framed Protocol should be started for the User, such as PPP or SLIP. </quote> > > The word, 'framed' sounds a 'real convention' per the above statement, because we might use it not only for PPPoE, but also for IPoE in the broadband access. I guess it might mean 'nothing' in this case. > > > Best Regards, > Leaf > > > > ----------------------------------------------------------------------------------------------------------------- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Benoit Claise > Sent: Friday, August 10, 2012 11:04 PM > To: draft-ietf-radext-ipv6-access@tools.ietf.org > Cc: radext@ietf.org > Subject: [radext] AD review: draft-ietf-radext-ipv6-access-11 > > Dear authors, > > Here is my review. Mainly editorial > > - Radius -> RADIUS > > - In section 2.1 and section 2.5 > > OLD: > > DHCPv6 [RFC3315] provides a mechanism to assign one or more or non- > temporary IPv6 addresses to hosts. > > NEW > DHCPv6 [RFC3315] provides a mechanism to assign one or more non- > temporary IPv6 addresses to hosts. > > - Extend "IPv6CP" something meaningful: PPP's IP v6 Control protocol > > - Section 2.3 > OLD: > This document specifies the RADIUS attribute that allows the AAA > system to provision the announcement by the NAS of a specific Route > Information Option to an accessing host. > > NEW: > This document specifies the RADIUS attribute that allows the AAA > server to provision the announcement by the NAS of a specific Route > Information Option to an accessing host. > > - Section 2.4 > DHCPv6-PD expands to prefix delegation > - Section 2.2 > Recursive DNS Servers. Why recursive? > Same remark for the section 3.2: > The DNS-Server-IPv6-Address Attribute contains the IPv6 address of a > recursive DNS server. This attribute MAY be included multiple times > in Access-Accept packets, when the intention is for a NAS to announce > more than one recursive DNS address to an RG/host. > - Section 3.4 > This Attribute contains the name of an assigned pool that SHOULD be > used to select an IPv6 delegated prefix for the user. If a NAS does > not support multiple prefix pools, the NAS MUST ignore this > Attribute. > > What is the user? It's confusing with the end user. > However, section 3.3 mentions: > This Attribute specifies a prefix (and corresponding route) for the > user on the NAS, ... > > So maybe the solution is: > OLD: > > This Attribute contains the name of an assigned pool that SHOULD be > used to select an IPv6 delegated prefix for the user. > > NEW: > > This Attribute contains the name of an assigned pool that SHOULD be > used to select an IPv6 delegated prefix for the user on the NAS. > > > Same remark for the section 3.5 > OLD: > This Attribute contains the name of an assigned pool that SHOULD be > used to select an IPv6 address for the user. > NEW: > This Attribute contains the name of an assigned pool that SHOULD be > used to select an IPv6 address for the user on the NAS. > > - Section 3.4 > If a NAS does not support multiple prefix pools, the NAS MUST > ignore this Attribute. > > I'm confused by the "multiple" > > Please provide a revised ID, including the editorial improvements from Leaf Yeh on the mailing. > Note: Leaf's comments came after the WG LC, but could be made again in the IETF LC. So let's ease everybody's live, and let's include them directly. > > > And, finally, for my personal education, where does the "framed" in the attribute naming convention come from? > > Regards, Benoit (OPS AD) > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > >
- [radext] AD review: draft-ietf-radext-ipv6-access… Benoit Claise
- Re: [radext] AD review: draft-ietf-radext-ipv6-ac… Leaf yeh
- Re: [radext] [MARKETING] Re: AD review: draft-iet… Benoit Claise