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

Benoit Claise <bclaise@cisco.com> Fri, 10 August 2012 15:04 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 E6C6221F8697 for <radext@ietfa.amsl.com>; Fri, 10 Aug 2012 08:04:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.477
X-Spam-Level:
X-Spam-Status: No, score=-10.477 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 sxp-CxRJ1-I9 for <radext@ietfa.amsl.com>; Fri, 10 Aug 2012 08:04:11 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 1456F21F8699 for <radext@ietf.org>; Fri, 10 Aug 2012 08:04:10 -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 q7AF4ADU015220; Fri, 10 Aug 2012 17:04:10 +0200 (CEST)
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q7AF48MK008621; Fri, 10 Aug 2012 17:04:09 +0200 (CEST)
Message-ID: <502522E8.1080700@cisco.com>
Date: Fri, 10 Aug 2012 17:04:08 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: draft-ietf-radext-ipv6-access@tools.ietf.org
Content-Type: multipart/alternative; boundary="------------090804020207040808000304"
Cc: radext@ietf.org
Subject: [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: Fri, 10 Aug 2012 15:04:13 -0000

Dear authors,

Here is my review. Mainly editorial

- Radius -> RADIUS

- In section 2.1 and section 2.5

OLD:

    DHCPv6 [RFC3315  <http://tools.ietf.org/html/rfc3315>] provides a mechanism to assign one or more or non-
    temporary IPv6 addresses to hosts.

NEW
    DHCPv6 [RFC3315  <http://tools.ietf.org/html/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)