Subject: [Dime] Comments on draft-ietf-dime-mip6-integrated-03.txt

From: David Frascone <[email-masked]>
Date: Mon, 19 Mar 2007 13:39:01 -0400

Comments:

1. Introduction:

   However, static provisioning of this information becomes
   easily provisioning and network administratiOn burden for an
   operator.

   maybe change to:

   However, static provisioning of this information can easily
   become a provisioning and network administration burden for
   operators.

Section 4.1

   Diameter nodes conforming to this specification SHOULD include the
   value of 1 (NASREQ application) or 5 (EAP application) in the Auth-
   Application-Id or the Acct-Application-Id AVP in the Capabilities-
   Exchange-Request and Capabilities-Exchange-Answer commands

   Shouldn't that SHOULD be a MUST?  In what scenarios would the
   Auth-Application-Id not be 1 or 5?

Section 4.7.3, last sentance:

   There may be reasons for
   the Diameter server to dynamically assigning home link prefix to the
   MN, for example one that is in close proximity to the point of
   attachment.

   maybe change to:

   There may be reasons for the Diameter server to dynamically
   assign a home link prefix to the MN, for example if it is
   in close proximity to the point of attachment.

Section 5.2

    Are the SHOULD's in there really MUST's?  In what cases would the
    Diameter server NOT send those AVPs, since we've already said
    that the server supports the assignment.

General question
    What is sent by the Diameter Client to the Diameter Server in the
    new AVP's?  Most of the information is not known, and will be
    provided by the Diameter Server.  Are they just empty placeholders?
    If so, it seems like a lot of waste to essentially do a capabilities
    announcement.

-- 

David Frascone

                     If it's not your banana, don't eat it.

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: <[email-masked]>
Date: Mon, 19 Mar 2007 19:07:49 +0100

Hi,

Thanks for the review! See my comments inline. 

> -----Original Message-----
> From: David Frascone [mailto:[email-masked]] 
> Sent: 19. maaliskuuta 2007 19:39
> To: [email-masked]
> Subject: [Dime] Comments on draft-ietf-dime-mip6-integrated-03.txt
> 
> 
> Comments:
> 
> 1. Introduction:
> 

OK.

>    Auth-Application-Id not be 1 or 5?

Hmmm.. MUST works for me. 

>    in close proximity to the point of attachment.

OK.

>     that the server supports the assignment.

If the subscription does not have MIP6 provisioned but the Diameter
server still provides access authentication for the said subscription.
In this case the server would not send any MIP6 bootstrapping AVPs
back to the NAS.

>     If so, it seems like a lot of waste to essentially do a 

Hmm.. the Diameter client does not need to send all new AVPs. One
is enough for the capability announcement. If the Diameter client does
not have anything sensible to put into an AVP it should not send one.
For the MIP6-Home-Agent-Address we actually defined the value to use
when the information is unknown. Maybe we should limit the 
capability announcment to only one AVP..

Actually, a specific AVP for the capability was proposed again.
We are thinking to re-introduce a capability AVP back to accommodate one
particular local HA assignment use case.

Cheers,
	Jouni

---

From: David Frascone <[email-masked]>
Date: Mon, 19 Mar 2007 16:07:13 -0400

One comment below:

> In this case the server would not send any MIP6 bootstrapping AVPs
Would it be possible to add some text to explain that, then?  Otherwise
the SHOULD is kind of ambiguous.

-Dave

-- 

David Frascone

              Move your vowels every day or you'll get consonated.

---

From: <[email-masked]>
Date: Tue, 20 Mar 2007 09:26:19 +0100

Hi Dave, 

> Would it be possible to add some text to explain that, then?  
> Otherwise the SHOULD is kind of ambiguous.

Sure. I'll propose some clarifying text later on.

Cheers,
	Jouni