Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13

From: Heejin Jang <[email-masked]>
Date: Tue, 06 May 2008 04:44:55 +0000 (GMT)

Hi, Vijay. 
Sorry for the late reply due to my vacation till yesterday. 

Thanks for your kind feedback. 
Please see the below.

> -----Original Message-----
> From: Vijay Devarapallli [mailto:[email-masked]] 
> Sent: Wednesday, April 30, 2008 2:53 PM
> To: Jari Arkko; [email-masked]
> Cc: [email-masked]
> Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13
> 
> Hi Jari, Heejin,
> 
> Its been a while since I looked at this document. A few minor 
> comments.
> 
> The IANA registry for the sub-opt-code in the Home Network 
> Information option and the MIP6 Relay agent option should be 
> relaxed to "Standards Action or IESG approval". It would be 
> good if the sub-opt-code can be extended to carry additional 
> pieces of information using Experimental or Informational 
> RFCs in the future. Mentioning "Standards Action"
> means the sub-opt-code can only be extended by Standards Track RFCs.
> This would require a minor change in the IANA considerations section.

Ok. It will be reflected in next version.

> I think a new registry should be created for the Id-type 
> field in the Home Network Information option (section 3.1). 
> This is missing in the IANA considerations section. 

Ok. It will be reflected as below.
 
In Section 6, 

Old: 

In addition,
   a new name space "Home Network Information Option Id-type Values"
   should be created, again in the same registry.  Values 0, 1, and 2
   are assigned by this document as specified in Section 3.1.

New:

   IANA is requested to create a new registry for the Home Network
   Information Option Id-type Codes.

       o Visited domain (local ASP)               0
       o Target MSP                               1
       o No preference by the mobile node         2

> Another minor comment related to this.
> The value '0' should be used to indicate that the MN has no 
> preference, instead of the value '2' being used for no 
> preference and '0' used for visited domain home agent 
> information. That seems more conventional. But if this needs 
> too many changes in the document, don'
> t bother.

It makes sense. But the authors and AD worry about much changes, so 
hope to keep as it is unless it causes any problem.

> Finally, the introduction needs to be slightly re-written to 
> say that the main goal of this document is to deliver the  
> home agent information to the mobile node using stateless 
> DHCPv6. It currently seems to say that the mail goal is to 
> deliver a prefix so that the mobile node can run DHAAD using 
> that prefix. I don't remember if the introduction always used 
> to say this or if it was changed recently.

Ok. We mentioned the goal of the document clearly in the Section 1.

Old: 
...
Subsequently, the mobile node can engage in
   dynamic home agent discovery using the prefix information.  In
   addition to delivering the prefix information, DHCP can also be used
   to provide the IP addresses or FQDNs of the home agents that are
   available to the mobile node.  The solution involves defining a new
   DHCP option to carry home network prefix, home agent IP address and
   FQDN information.
...

New:
...
Subsequently, the mobile node can engage in
   dynamic home agent discovery using the prefix information.  In
   addition to delivering the prefix information, DHCP can also be used
   to provide the IP addresses or FQDNs of the home agents that are
   available to the mobile node.  The goal of this document is to
   deliver the home agent information to the mobile node by using
   stateless DHCPv6.  The proposed solution enables it by defining new
   DHCP options which carry home network prefix, home agent IP address
   and FQDN information.
...

> The document otherwise looks fine. Ready for approval by the IESG. :)

Thanks for your concerns again. :)

- Best regards, 
Heejin
 
> Vijay
> 
> On Mon, Apr 21, 2008 at 12:16 AM, Jari Arkko 
> <[email-masked]> wrote:
> > The last edits are in -15 now. Any additional people who want to 
> > comment  on this before its approved?
> >
> >  Jari
> >
> >
> >
> >  _______________________________________________
> >  MEXT mailing list
> >  [email-masked]
> >  https://www.ietf.org/mailman/listinfo/mext
> >
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Vijay Devarapallli" <[email-masked]>
Date: Tue, 6 May 2008 08:22:18 -0700

Hi Heejin,

Replying to just one issue below (the rest are fine with me)

>    DHCP options which carry home network prefix, home agent IP address

Not enough. The document needs to clearly state that the main goal is
to deliver the home agent information to the mobile node. The mobile
node MAY use the prefix to perform DHAAD if it wants to. Thats not the
primary goal. How about the following?

OLD:

   Before a mobile node can engage in Mobile IPv6 signaling with a home
   agent, it should either know the IP address of the home agent via
   pre-configuration, or dynamically discover it.  The Mobile IPv6
   specification [RFC3775] describes how home agents can be dynamically
   discovered by mobile nodes that know the home network prefix.  This
   scheme does not work when prefix information is not already available
   to the mobile node.  One architecture to solve this problem is
   described in [I-D.ietf-mip6-bootstrapping-integrated-dhc].  A part of
   the solution is the capability to deliver home network prefix
   information to the mobile node by means of the stateless DHCPv6
   [RFC3736] [RFC3315].  Subsequently, the mobile node can engage in
   dynamic home agent discovery using the prefix information.  In
   addition to delivering the prefix information, DHCP can also be used
   to provide the IP addresses or FQDNs of the home agents that are
   available to the mobile node.  The solution involves defining a new
   DHCP option to carry home network prefix, home agent IP address and
   FQDN information.

NEW:

   Before a mobile node can engage in Mobile IPv6 signaling with a home
   agent, it should either know the IP address of the home agent via
   pre-configuration, or dynamically discover it.  The Mobile IPv6
   specification [RFC3775] describes how home agents can be dynamically
   discovered by mobile nodes that know the home network prefix.  This
   scheme does not work when prefix information is not already available
   to the mobile node.  One architecture to solve this problem is
   described in [I-D.ietf-mip6-bootstrapping-integrated-dhc]. This document
   specifies extensions to stateless DHCPv6 [RFC3736] [RFC3315] to
   deliver the home agent information to the mobile node in the form of the
   IP address of the home agent or the FQDN of the home agent. The
   information delivered to the mobile node may also include the home
   prefix for the mobile node. The solution involves defining a new DHCP
   option to carry home network prefix, home agent IP address and FQDN
   information.

   The mobile node MAY also use the home prefix to discover the list of
   home agents serving the home prefix using the Dynamic Home Agent
   Address Discovery mechanism specified in RFC 3775.

Vijay