Subject: Re: [Dime] Diameter PMIPv6

From: jouni korhonen <[email-masked]>
Date: Mon, 1 Jun 2009 13:41:09 +0300

Hi Marco,

Thanks for the review. I have my responses inline.

On May 27, 2009, at 6:58 PM, Marco Liebsch wrote:

> Hi Jouni, all,
>
> please find a few thoughts about the current version of draft-ietf- 
> dime-pmip6-02
> attached. And sorry for the huge delay in providing comments. Hope  
> the comments
> style is clear. Anyway, proposed changes are optional :-) Hope it  
> helps.
>
> Best regards,
> marco
>
> Editorial for clarification:
> ============================
>
> 1. Introduction
>
> "..Dynamic assignment and downloading of PMIPv6 policy profile
> information is a desirable feature to ease the deployment and network
> maintenance of larger PMIPv6 deployments. "
>
>> you probably mean "..maintenance of larger PMIPv6 domains."

Yes.

>>
>
> ---
>
> "..The Diameter server in the
> Mobility Service authorizer's (MSA) network may return these
> parameters to the Network Access Server (NAS). "
>
>> you may add ".. to the Network Access Server (NAS) during access  
>> authentication."

Sounds OK. I'll add this.

>>
>
> --
>
> "..Once the MN authenticates to the network the MAG sends.."
>
>> Isn't it vice versa that the network authenticates the MN? You may  
>> change to
> "..Once the network has authenticated the MN, the MAG sends.." or
> "..Once the MN has identified to the network and the network has  
> authenticated
> the MN..."

Hmm.. well you could say it as "..Once the network has authenticated  
the MN, the MAG sends.."
I can change this as well.

>
>
> --
>
> "..The NAS functionality of the MAG may be co-located or an integral
> part of the MAG.."
>
>> I'd consider the NAS and the MAG as functional entities, which may be
> colocated on an access router. So, the proposed alternative may be
> "..The NAS functionality may be colocated with the MAG function on the
> network's access router.."

Yes, NAS & MAG are functional entities.
"The NAS functionality may be co-located with the MAG function in the
  network's access router."

>
>
> --
>
> 3. Solution Overview
>
> "..This document defines Diameter based AAA interactions between the
> MAG and the HAAA, and between the LMA and the HAAA."
>
>> Hmm, since the extension is generic for any interface between a  
>> Diameter Client and
> Diameter Server, I'd consider such operation also useful with a AAA  
> in the visited network.
> So, why limiting this to the HAAA? I'd suggest to write simply AAA.
> Loading profile info is anyway transparent, as the AAAvisited contacts
> the AAAhome.

Hmm.. eventually the AAA signaling will hit the Home AAA server where  
the subscription & policy profile is store. Whether the AAA signaling  
goes through some AAA nodes in the visited network in transparent  
typically.

>
>
> --
>
> 4.2 PMIP6-IPv4-Home-Address AVP
>
>> Would it make sense to include a BNF of this AVP as well?
> Or provide a reference here to the document where the
> type Address is defined.

I'll add the reference here.. and all other places where rfc3588  
additional types are used.

>
>
> --
>
> Section 5.1
>
>> Some text as you have it at the beginning of Section 5.1 I'd
> propose to have much earlier to understand what the document is about,
> which problem it addresses and which protocol extensions it proposes
> to solve the problem.

Hmm.. right. I could move the whole Section 5 immediately after  
Section 3, just before going to AVP descriptions.

>
>
> General comments:
> ================
>
> As the spec does not define a new application for PMIPv6 anymore,  
> can the text
> or even the title reflect that it's in fact a Generic Extension to  
> Diameter
> Applications for Proxy MIPv6? So far it says it's Diameter Support for
> Proxy Mobile IPv6.

Good point. Will add such claim there.

>
>
> I'd be more precise and clear in 1. Introduction and the beginning of
> 3. Solution Overview about what the specification does. Well, the  
> intro
> says what PMIPv6 demands and what NAS does. Then it says that the spec
> defines the Diameter support for PMIPv6 (to do what?) and that the NAS
> may be colocated with the MAG.. The Intro looks very unsystematic to  
> me.
> All this is ok if you (as reader) know the details of why and how  
> you're
> doing this. I'd recommend that in the Intro you're precise with  
> describing
> the problem, the existing protocols you can re-use and extend and  
> with what
> you specify in this document to solve the problem. Then it should be  
> ok for
> most readers to understand the rest.

Right. I'll have a look at this and propose some better wording.

>
>
> One feature of the LMA-AAA interface should be HNP delegation, where  
> the
> LMA can request an HNP for the MN from the AAA during mobility session
> authorization. As far as I remember, this was in some time ago (?  
> maybe not..).
> Would be good to have this feature mentioned in the spec, e.g.  
> Section 1 and
> Secion 5.2.

The HNP delegation is still mentioned in Section 4.3 so it is there.  
But I can point it out more clearly in those sections you pointed out.

Cheers,
	Jouni