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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]