Re: [radext] AD review: draft-ietf-radext-ipv6-access-11

Leaf yeh <leaf.y.yeh@huawei.com> Mon, 13 August 2012 08:17 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 4D95E21F86C3 for <radext@ietfa.amsl.com>; Mon, 13 Aug 2012 01:17:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.45
X-Spam-Level:
X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 UfIMmrxJLT9Z for <radext@ietfa.amsl.com>; Mon, 13 Aug 2012 01:17:01 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id D183D21F86BB for <radext@ietf.org>; Mon, 13 Aug 2012 01:17:00 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIU31921; Mon, 13 Aug 2012 00:17:00 -0800 (PST)
Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 13 Aug 2012 01:15:15 -0700
Received: from SZXEML438-HUB.china.huawei.com (10.72.61.73) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 13 Aug 2012 01:15:14 -0700
Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.103]) by szxeml438-hub.china.huawei.com ([10.72.61.73]) with mapi id 14.01.0323.003; Mon, 13 Aug 2012 16:15:06 +0800
From: Leaf yeh <leaf.y.yeh@huawei.com>
To: Benoit Claise <bclaise@cisco.com>, "draft-ietf-radext-ipv6-access@tools.ietf.org" <draft-ietf-radext-ipv6-access@tools.ietf.org>
Thread-Topic: [radext] AD review: draft-ietf-radext-ipv6-access-11
Thread-Index: AQHNdwl01+IPRcbh5UqVSBmY8vv1ipdXVSlg
Date: Mon, 13 Aug 2012 08:15:05 +0000
Message-ID: <E1CE3E6E6D4E1C438B0ADC9FFFA345EA3C4581BD@SZXEML510-MBS.china.huawei.com>
References: <502522E8.1080700@cisco.com>
In-Reply-To: <502522E8.1080700@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: "radext@ietf.org" <radext@ietf.org>
Subject: Re: [radext] 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: Mon, 13 Aug 2012 08:17:02 -0000

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)