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

[Jari Arkko <[e-mail]>]

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