[netext] AD review of draft-ietf-netext-radius-pmip6

Jari Arkko <jari.arkko@piuha.net> Sun, 11 December 2011 22:44 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE9A21F849D for <netext@ietfa.amsl.com>; Sun, 11 Dec 2011 14:44:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.544
X-Spam-Level:
X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 OcDQ77Rjv5Vv for <netext@ietfa.amsl.com>; Sun, 11 Dec 2011 14:44:35 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 96D0F21F845D for <netext@ietf.org>; Sun, 11 Dec 2011 14:44:35 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D0A5C2CC43; Mon, 12 Dec 2011 00:44:33 +0200 (EET)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rj9jADtRhTqD; Mon, 12 Dec 2011 00:44:33 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id CE13D2CC31; Mon, 12 Dec 2011 00:44:32 +0200 (EET)
Message-ID: <4EE5324E.3010803@piuha.net>
Date: Mon, 12 Dec 2011 00:44:30 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111110 Thunderbird/8.0
MIME-Version: 1.0
To: draft-ietf-netext-radius-pmip6@tools.ietf.org, "netext@ietf.org" <netext@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [netext] AD review of draft-ietf-netext-radius-pmip6
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 11 Dec 2011 22:44:36 -0000

I have reviewed this specification.

The draft is well written. Thanks for that. I only found a couple of minor editorial issues, and one technical issue. I would like to talk about the technical issue before we send the draft forward. Please reply to this e-mail and/or revise the draft accordingly so that I can start an IETF Last Call.

Section 4.9: Shouldn't this section include some text about not including this attribute, if MIP6-Home-HN-Prefix is already present? (Like Section 4.7 had for its corresponding attribute pair.) The same problem may appear in Section 4.13 and elsewhere as well. Please check.

Section 4.10 & 4.11: This is the technical issue that worries me. While RFC 5213 does say that there are cases where MN-HoA is known, this is certainly an exception rather than the rule:

    Mobile Node's Home Address (MN-HoA)

       MN-HoA is an address from a mobile node's home network prefix.
       The mobile node will be able to use this address as long as it is
       attached to the access network that is in the scope of that Proxy
       Mobile IPv6 domain.  If the mobile node uses more than one address
       from its home network prefix(es), any one of these addresses is
       referred to as mobile node's home address.  Unlike in Mobile IPv6
       where the home agent is aware of the home address of the mobile
       node, in Proxy Mobile IPv6, the mobility entities are only aware
       of the mobile node's home network prefix(es) and are not always
       aware of the exact address(es) that the mobile node configured on
       its interface from its home network prefix(es).  However, in some
       configurations and based on the enabled address configuration
       modes on the access link, the mobility entities in the network can
       be certain about the exact address(es) configured by the mobile
       node.

Sections 4.10 and 4.11 talk about IIDs without any context on how they should be derived, used, and whether they can even exist on a given deployment.

One approach to fix this would be to delete the subsections. Another one would be explain how the IID values are determined, when they can be determined, and how they should be used. Yet another approach is to point me (and the reader) to another RFC that describes this (as I could of course have missed something).

> 4.18.  Calling-Station-Id
>
>    The Calling-Station-Id attribute (Type value 31) is of type String
>    and when used for PMIPv6 it contains the link-layer identifier of the
>    MN as defined in [RFC5213], Sections 2.2 and 8.6.

You should refer to the RFC that originally defined Calling-Station-Id.

>    The User-Name attribute MUST be present in the Access-Request.  It
>    SHOULD carry a valid MN identity unless the identity is being
>    suppressed for policy reasons, for example, when identity hiding is
>    in effect.  The MN identity, if available, MUST be in Network Access
>    Identifier (NAI) [RFC4282] format.

I think there is always an identifier that is of the valid form. It just may not reveal the identity of the user (at least not in an 1-1 and stable fashion). Consider making this change:

... MUST carry a correctly formed identifier that SHOULD correspond to a MN identity unless ...

Jari