Subject: [Gen-art] Gen-ART Review of draft-ietf-dime-pmip6-02.txt

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 4 Aug 2009 14:45:57 -0500

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...

   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".

      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.

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?

   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?

   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.

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 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...".

   ongoing PMIPv6 session is in progress.

---

From: jouni korhonen <[email-masked]>
Date: Thu, 6 Aug 2009 14:57:34 +0300

Hi Spencer,

Thanks for the review. See my responses inline.

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

> Summary: This specification is almost ready for publication as a  
> Proposed Standard. I have some minor comments, mostly involving 2119  
> language.
>
> 1.  Introduction
>
> 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.

> Spencer (clarity): I'd say "if this bit is cleared".

OK.

> 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.

> Spencer (minor): why is this a SHOULD, and not a MUST?

I would be fine with MUST here.

> Spencer (minor): what is this SHOULD conditional on?

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

> Spencer (nit): missing period here.

OK.

> 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..

> 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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 6 Aug 2009 12:02:51 -0500

Hi, Jouni,

Thanks for the quick response. If I wasn't still jet-lagged, I could 
remember what I was thinking when I did the review :-)

Responses inline... and I deleted stuff we already agreed on.

Spencer

>> 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:
>

Much clearer - thanks!

>> 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.

If people think it's clear enough, that's fine. I was just getting lost.

> 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.

That's fine.

Sorry for asking three questions back-to-back.

The question that may have gotten lost is "who is required to support 
this?" - the MAG, or the HAAA, or both? This statement occurs in text that 
describes the message flow. I'm understanding your response as saying that 
the requirement applies to the MAG, but one reasonable interpretation is 
that it applies to both the MAG and HAAA (since they exchange messages with 
this AVP).

Suggest "The MAG SHOULD support this policy feature on a per MN and 
subscription basis".

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

Ah - if my understanding is correct, the text might be clearer as "Whenever 
the MAG sends a Diameter request message to the HAAA and identity hiding is 
not in effect, the User-Name MUST contain the MN's identity".

---

From: jouni korhonen <[email-masked]>
Date: Mon, 10 Aug 2009 00:31:12 +0300

Hi Spencer,

Sorry for the lag.. sometimes holidays interfere working ;) See more  
comments inline.

> Responses inline... and I deleted stuff we already agreed on.

Ack.

>>> subscriber policy profile"? If it doesn't, I'm too confused to  
>>> make  a suggestion...
>>
>> How about:
>>

Ok. Will change the text according to this.

>>> 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.
>

I'll change the text according to "supported per-MN and per- 
subscription basis" as it definitely clearer.

>
>> 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.
>
> That's fine.
>
> The question that may have gotten lost is "who is required to  
> support this?" - the MAG, or the HAAA, or both? This statement  
> occurs in text that describes the message flow. I'm understanding  
> your response as saying that the requirement applies to the MAG, but  
> one reasonable interpretation is that it applies to both the MAG and  
> HAAA (since they exchange messages with this AVP).
>

This is OK.

> Ah - if my understanding is correct, the text might be clearer as  
> "Whenever the MAG sends a Diameter request message to the HAAA and  
> identity hiding is not in effect, the User-Name MUST contain the  
> MN's identity".

I am still a bit hesitant with the MUST here. Anyway, if other authors  
don't disagree I am ok with the proposed change.

Cheers,
	Jouni

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sun, 9 Aug 2009 17:31:09 -0500

i think we're down to one item...

>> identity hiding is not in effect, the User-Name MUST contain the  MN's 
>> identity".
>

I would be OK with a SHOULD - you've provided at least one reason why it's 
not an unconditional MUST - but please check with other authors and doc 
shepherd.

thanks for the quick responses!

spencer

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 17 Aug 2009 08:05:28 -0400

Hi, Julian,

If this is a concern, I would be FINE with text that says

"Whenever the MAG sends a Diameter request message to the HAAA, the 
User-Name SHOULD contain the MN's identity unless the identity is being 
suppressed for policy reasons - for example, when identity hiding is in 
effect."

Does that help?

Thanks,

Spencer

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, August 17, 2009 7:57 AM
Subject: RE: Gen-ART Review of draft-ietf-dime-pmip6-02.txt

Hello,

 thanks for your Gen-ART review... one comment below:

> -----Message d'origine-----
> De : Spencer Dawkins [mailto:[email-masked]]
> Envoyé : lundi 10 août 2009 00:31
> À : jouni korhonen
> Cc : [email-masked]; General Area Review Team
> Objet : Re: Gen-ART Review of draft-ietf-dime-pmip6-02.txt
>
> >>>> User-Name AVP SHOULD contain the MN's identity.  The MN
> identity,
> >>>> if
> >>>>
> I would be OK with a SHOULD - you've provided at least one
> reason why it's not an unconditional MUST - but please check
> with other authors and doc shepherd.

 I'm ok with the proposed text. I just hope there's no other case where the 
User-Name may not be available.

 Regards,

 Julien

> >>>> 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
>
>

---

From: jouni korhonen <[email-masked]>
Date: Mon, 17 Aug 2009 16:14:40 +0300

Sounds OK to me.

cheers,
	Jouni

On Aug 17, 2009, at 3:05 PM, Spencer Dawkins wrote:

> User-Name SHOULD contain the MN's identity unless the identity is  
> being suppressed for policy reasons - for example, when identity  
> hiding is in effect."
>
> Does that help?
>
> Thanks,
>
> Spencer
>
> ----- Original Message ----- From: <[email-masked] 
> >
> I'm ok with the proposed text. I just hope there's no other case  
> where the User-Name may not be available.
>
> Regards,
>
> Julien
>
>>

---

From: <[email-masked]>
Date: Mon, 17 Aug 2009 13:57:09 +0200

Hello,

> with other authors and doc shepherd.

 I'm ok with the proposed text. I just hope there's no other case where the User-Name may not be available.

 Regards,

 Julien

---

From: <[email-masked]>
Date: Mon, 17 Aug 2009 14:07:36 +0200

Hi spencer,

 It sounds good to me. Thanks

 Regards,

 Julien 

> Envoyé : lundi 17 août 2009 14:05
> À : BOURNELLE Julien RD-CORE-ISS; [email-masked]
> Cc : [email-masked]; [email-masked]
> "Whenever the MAG sends a Diameter request message to the 
> HAAA, the User-Name SHOULD contain the MN's identity unless 
> the identity is being suppressed for policy reasons - for 
> example, when identity hiding is in effect."
> 
> Does that help?
> 
> Thanks,
> 
> Spencer
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 24 Aug 2009 12:38:18 -0500

Version 03 resolves all of the comments I had on -02. Ready for publication 
as Proposed Standard.

Thanks,

Spencer

> Spencer (clarity): I got lost in this sentence. Suggest "to inform the 
> HAAA that the termination of...".
>
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art