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
>
>