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

From: Heejin Jang <[email-masked]>
Date: Thu, 08 May 2008 11:22:41 +0000 (GMT)

I see. Now I can know what you meant. 
The proposed text looks good and I'll reflect it in the next version. 
 
Thanks for your kind help again. :)
 
- Best regards, 
Heejin.

------- Original Message -------
Sender : Vijay Devarapallli<[email-masked]>
Date   : 2008-05-07 00:22 (GMT+09:00)
Title  : Re: Re: [MEXT] FW: Summary for the changes in hiopt-13

Hi Heejin,

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

On Mon, May 5, 2008 at 9:44 PM, Heejin Jang <[email-masked]> wrote:

>  > 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&#39;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.
>  ...

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
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Jari Arkko <[email-masked]>
Date: Mon, 19 May 2008 19:12:01 +0300

Hi all,

I have reviewed this thread and re-reviewed the draft. While I
sympathize with some of the questions Alex had, I see no technical
reason to block the draft from being approved, and I see no support from
the WG from doing this either. So I am now approving the document.

However, as a re-read the draft, I also noticed two additional issues.
The first issue is that Section 3 seems to be forgetting the case where
DHCP server has no information about a particular home network. Due to
this, I would like to make the following change:

OLD:
In a network where the NAS is not co-
located with a DHCP relay nor a server, the server may not be
provided with the home network information from the NAS, and thereby
it may assign to a mobile node the home information which has been
preconfigured by the administrator or which is acquired through a
mechanism that is not described in this document.
NEW:
In a network where the NAS is not co-
located with a DHCP relay nor a server, the server may not be
provided with the home network information from the NAS, and thereby
it may either fail to provide information, or provide home information
which has been preconfigured by the administrator or which is acquired
through a mechanism that is not described in this document.

Secondly, Section 4.2 and 4.3 talk about how relays can provide
information to servers. But I cannot see how the server knows which
piece of information from the relay corresponds to what Home Information
Option, in case there were multiple options with different home network
names. I am a bit uncertain how to fix this, however. Perhaps it is
necessary to allow suboption type 1 in relay agent options, too.

Please suggest text, and I will place it in the RFC Editor note part of
the tracker and approve it. (Or you can submit a new version with these
fixes.)

Jari