Subject: Re: [MEXT] hiopt

From: Heejin Jang <[email-masked]>
Date: Tue, 20 May 2008 08:34:33 +0000 (GMT)

Hi, Jari.
Thanks for your mail.
Please see the inline.

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Tuesday, May 20, 2008 1:12 AM
> To: [email-masked]
> Cc: Vijay Devarapallli; [email-masked]; Alexandru Petrescu
> Subject: hiopt
> 
> 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.

Ok.

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

Actually this was considered when working on hiopt-03 where
the relay is supposed to put an MN-NAI into the MIP6 relay option when relaying 
DHCP messages to the server. At that time I was also considered putting the 
(home) MSP too, but left it without further description because I'm not sure that
we can mandate that the AAA server MUST deliver the home MSP's FQDN.

1) If yes, home MSP's FQDN can be delivered in suboption type 1 in the relay options 
as you suggested. (this will be finally compared with the target MSP requested by MN.).

2) If no, the server should return a (partially) matched HA FQDN, or a (partially) matched
HN prefix/HA address after DNS resolution based on the target MSP requested by MN.

It seems that 1) looks more explicit. 
Could you let me know your opinion?
 
> 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

Thanks again. :)

-Best regards, 
Heejin.
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Jari Arkko <[email-masked]>
Date: Tue, 20 May 2008 12:06:19 +0300

> Could you let me know your opinion?

I prefer option 1, but you need to change text earlier in the draft
about where suboption 1 is legal.

Make the changes, and submit a new version.

Jari