Re: Gen-ART Review of draft-ietf-dime-pmip6-02.txt

[jouni korhonen <[e-mail]>]

Hi Spencer,

Thanks for the review. See my responses inline.


On Aug 4, 2009, at 10:45 PM, Spencer Dawkins wrote:

> I have been selected as the General Area Review Team (Gen-ART)  
> reviewer for
> this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
> Please wait for direction from your document shepherd or AD before  
> posting a
> new version of the draft.
>
> Document: draft-ietf-dime-pmip6-02.txt
> Reviewer: Spencer Dawkins
> IETF LC End Date: 2009-08-05
> Review Date: 2009-08-03
> IESG Telechat date: (not known)
>
> Summary: This specification is almost ready for publication as a  
> Proposed Standard. I have some minor comments, mostly involving 2119  
> language.
>
> 1.  Introduction
>
>  This specification defines the Diameter support for PMIPv6.  In the
>  context of this specification the location of the subscriber policy
>  profile equals to the home Diameter server, which is also referred as
>
> Spencer (clarity): this sentence is difficult to parse - is it  
> saying "In this specification, the home Diameter server, which is  
> also referred to as the home AAA server (HAAA), contains the  
> subscriber policy profile"? If it doesn't, I'm too confused to make  
> a suggestion...

How about:

	In the context of this specification the home AAA server (HAAA)
	functionality is co-located with the subscriber policy profile.


>
>  the home AAA server (HAAA).  The NAS functionality of the MAG may be
>  co-located or an integral part of the MAG.
>
> 4.5.  MIP6-Feature-Vector AVP
>
>  LOCAL_MAG_ROUTING_SUPPORTED (0x0000040000000000)
>
>     Direct routing of IP packets between MNs anchored to the same MAG
>     is supported.  When a MAG sets this bit in the MIP6-Feature-
>     Vector, it indicates that routing IP packets between MNs anchored
>     to the same MAG is supported, without reverse tunneling packets
>     via the LMA or requiring any Route Optimization related signaling
>     (e.g. the Return Routability Procedure in [RFC3775]) prior direct
>     routing.  If this bit is unset in the returned MIP6-Feature-Vector
>
> Spencer (clarity): I'd say "if this bit is cleared".

OK.


>
>     AVP, the HAAA does not authorize direct routing of packets between
>     MNs anchored to the same MAG.  This policy feature SHOULD be
>     supported per MN and subscription basis.
>
> Spencer (minor): it's not clear who SHOULD be supporting this  
> feature - who does the 2119 SHOULD apply to? I would guess it  
> applies to the MAG, but I'm guessing. Is this "supported on a per-MN  
> and per-subscription basis"? And I'm not sure why this SHOULD isn't  
> a MUST.

"supported on a per-MN and per-subscription basis" is what the text  
tries to say.

It is SHOULD as the RFC5213 does not mandate whether the local routing  
is per-MN (uses MAY in RFC5213) or applies to whole MAG. Therefore, we  
felt SHOULD is enough and final decision is then left for the  
deployment/system.


>
> 4.8.  Service-Selection AVP
>
>  It is also possible that the MAG receives the service selection
>  information from the MN, for example, via some lower layer mechanism.
>  In this case the MAG SHOULD include the Service-Selection AVP also in
>
> Spencer (minor): why is this a SHOULD, and not a MUST?

I would be fine with MUST here.


>
>  the MAG-to-HAAA request messages.  In absence of the Service-
>  Selection AVP in the MAG-to-HAAA request messages, the HAAA may want
>  to inform the MAG of the default service provisioned to the MN and
>  include the Service-Selection AVP in the response message.
>
> 5.1.  MAG-to-HAAA Interface
>
>  Whenever the MAG sends a Diameter request message to the HAAA the
>  User-Name AVP SHOULD contain the MN's identity.  The MN identity, if
>
> Spencer (minor): what is this SHOULD conditional on?

In case of identity hiding is applied, the User-Name can be absent.

>
>  available, MUST be in Network Access Identifier (NAI) [RFC4282]
>  format.  At minimum the home realm of the MN MUST be available at the
>  MAG when the network access authentication takes place.  Otherwise
>  the MAG is not able to route the Diameter request messages towards
>  the correct HAAA.  The MN identity used on the MAG-to-HAAA interface
>  and in the User-Name AVP MAY entirely be related to the network
>  access authentication, and therefore not suitable to be used as the
>  MN-ID mobility option value in the subsequent PBU/PBA messages.  See
>  the related discussion on MN's identities in Section 4.6 and in
>  Section 5.2.1
>
> Spencer (nit): missing period here.

OK.

>
> 5.2.1.  Authorization of the Proxy Binding Update
>
>  Whenever the LMA sends a Diameter request message to the HAAA, the
>  User-Name AVP SHOULD contain the MN's identity.  The LMA MAY retrieve
>
> Spencer (minor): what is this SHOULD conditional on?

The "profile" for LMA-HAAA proposed in this specification is going to  
be used on top of some other application. That some other application  
may not use User-Name, thus we felt SHOULD is strong enough to give  
guidance to do so..

>
>  the MN's identity information from the PBU MN-ID [RFC4283][RFC5213]
>  mobility option.  The identity SHOULD be the same as used on the MAG-
>  to-HAAA interface, but in the case those identities differ the HAAA
>  MUST have a mechanism of mapping the MN identity used on the MAG-to-
>  HAAA interface to the identity used on the LMA-to-HAAA interface.
>
> 6.1.  Session-Termination-Request
>
>  The LMA or the MAG MAY send the Session-Termination-Request (STR)
>  command [RFC3588] to the HAAA and inform the termination of an
>
> Spencer (clarity): I got lost in this sentence. Suggest "to inform  
> the HAAA that the termination of...".
>

The proposed change looks good to me.

Cheers,
	Jouni



>  ongoing PMIPv6 session is in progress.