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

[jouni korhonen <[e-mail]>]

Jari,

Version -06 addressing your concerns has been submitted.

- Jouni


On Jan 2, 2012, at 1:10 PM, Jari Arkko wrote:

> Jouni,
> 
> I was going through my list of drafts today and noticed that I had not responded to your reply yet:
> 
>> Jari,
>> 
>> Thanks for the detailed review. See my comments online.
>> 
>> On Dec 12, 2011, at 12:44 AM, Jari Arkko wrote:
>> 
>>> 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.
>> If I recall our (authors) discussion correctly the motivation not to add any restriction in these cases was to allow a (possible future) deployment where the MAG receives both home&  visited LMA addresses and then picks based on some policy either one. For this to work, we would need address allocation also have the same functionality. No problem to add "SHOULD NOT"s there and explain the situation.
> 
> OK
> 
>> 
>>> 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).
>> Right, good point. I would remove the "derivation text" and add applicability statement for links where the network actually delivers the IID to the end host (PPP, 3GPP, ...) these attributes contain the IID.
> 
> Good.
> 
>> 
>>>> 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.
>> Ack.
>> 
>>>>   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 ...
>> Ok. Will change.
>> 
>> 
> 
> Great. Will ýou post a new draft version so that we can move this document forward?
> 
> Jari
>