Subject: Re: [MEXT] why having DHCP do DNS resolution? (was: FW: Summary for the changes in hiopt-13)

From: "Alper Yegin" <[email-masked]>
Date: Fri, 9 May 2008 13:26:55 +0300

Hi Alex,

The issue at hand is roaming, and identification of realm (as opposed to
identification of the host). That's what the realm portion of the NAI is for
(in other IETF specs), and that's how it is also used in this spec as well.

I hope this clarifies. 

Alper
Samsung 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alexandru Petrescu
> Sent: Wednesday, April 30, 2008 12:41 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [MEXT] why having DHCP do DNS resolution? (was: FW: Summary
> for the changes in hiopt-13)
> 
> Heejin Jang wrote:
> > Hi, Alex. See below.
> >
> > ps> I'm supposed to have a vacation till next Monday, and cannot
> > access my samsung account. So kindly refer my gmail account as well.
> 
> Heejin, enjoy vacations :-)  when back in office see below.
> 
> [...]
> >> Then I don't see why stateless DHCPv6 is needed for this?  Plain
> >> full DHCPv6 can accommodate this scenario.
> >
> > Basically plain (stateful) DHCPv6 is used for address configuration
> > while stateless DHCPv6 is for other parameters configuration such as
> >  DNS server address. So this HN information should be delivered
> > through stateless DHCPv6.
> 
> Let's clarify this use of Stateless DHCPv6 RFC3736.
> 
> Why does a hiopt MN need to include a Home Network Identifier
> (Sub-Opt-Code 1, eg realm of NAI) in the Home Network Information Option
> in the Information-Request?  Why isn't it sufficient to use the Client
> Identifier Option DUID section 22.2 of RFC 3315 DHCPv6.
> 
> Why isn't the DUID enough to identify the Client (1 - Link-layer address
> plus time, 2 - vendor-assigned unique id based on enterprise number, 3 -
> link-layer address).
> 
> Why is it thought that it is necessary to specify Home Network
> Identifier Sub-Opt-Code 1 as being, for example, the realm part of a
> NAI, when the DUID exists, is used and covers a different range of cases.
> 
> >>>> I think that RFC doesn't suggest the Client to put data in a
> >>>> request and the Server to suggest back a different data.  Or,
> >>>> apparently, a hiopt-13 Client puts  IPv6 home network prefix in
> >>>>  a Request, with sub-opt-code equal 2, Relay forwards it to
> >>>> Server, and Server puts another IPv6 home network prefix in a
> >>>> Reply, apparently. Is this the intended hiop-13 behaviour?
> >>>>
> >>>> Is this behaviour in this sense completely different than the
> >>>> typical
> >>>>
> >>>> DHCPv6 operation?
> >>>
> >>> Section 3.3 says
> >>>
> >>> " While the Sub-opt-code 1 is only available in both the
> >>> requesting and the returned Home Network Information options,
> >>> Sub-opt-codes 2, 3, 4, and 5 are available only in the returned
> >>> Home Network Information option and the MIP6 Relay Agent option."
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Section 4.1 says
> >>>
> >>> "  A value of 1 is the only Sub-opt-code available in the
> >>> request."
> 
> Right, now makes better sense.  For easing my humble reading this
> statement could appear in section 3.1 where the message encoding of Home
> Network Information Option is described.
> 
> >>> An MN cannot carry sub-opt-codes other than 1. This means that a
> >>>  sub-option in the request is used only to carry the MN's
> >>> prefered target MSP in case of id-type 1 so that the server can
> >>> reply the matching HA information.
> >>>
> >>> So, the server never replys with "the different" data.
> >> Right, thanks, now I understand it better as being the basic hiopt
> >>  behaviour.
> >>
> >> Let me agree with you for a short while that it's good to identify
> >>  the subnet by a FQDN.
> >>
> >> If so basically MN (DHCP Client) puts FQDN in the request and the
> >> DHCP Server sends back an IP address of the Home Agent.
> >>
> >> How is this different than DNS Resolution?  Why do we need DHCP to
> >>  do DNS Resolution?
> >
> > While MNs are required to know an exact FQDN of the target (HA) for
> > DNS resolution, DHCP discovery enables HA discovery in variable ways
> > even in case MN does not have exact information about its home
> > network. For e.g. it can request the local HAs with the id-type 0. Or
> >  the server may return partially matching HA information as described
> >  in Section 4.3.
> 
> I agree at high level but not in detail.
> 
> The really big problem here - and in all bootstrapping documents - is
> that we have not precisely described what is the information available
> at the MN prior to bootstrapping phase.  Different documents make
> different assumptions and they overlap.
> 
> [skipped some for focusing the discussion]
> 
> > IMHO, such a load-balancing approach is wellknown and does not need
> > to be limited to VPN. Anyway here the key point is "to provide HA
> > information based on NAI" can be implemented in various ways as least
> >  by using 1) and 2)  as described in previous mails.
> 
> If it is the key point then it should be much more clear than that.
> It is far from being clear.  Now here it's said "NAI" but in the
> document it's said "for example, the realm part of NAI".  If we decide
> to do only NAI-based HA address bootstrapping with DHCPv6 then I can
> agree we can have a better document.
> 
> That is a big if.
> 
> Because - does DHCPv6 or DHCPv4 ever use NAI for address allocation or
> parameter configuration?  I don't think so.  They use MAC address (or
> DUID) but not NAI.  I find hiopt very much different than DHCPv6 in this
> sense.  IMHO. ?.
> 
> If one wants to use NAI (or its realm part) to find the corresponding IP
> address then use DNS straight resolution, not DHCP.
> 
> Alex
> 
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
> _______________________________________________
> 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: Alexandru Petrescu <[email-masked]>
Date: Fri, 09 May 2008 22:11:16 +0200

> (in other IETF specs), and that's how it is also used in this spec as well.

Alper - what is 'roaming'?

Alex

---

From: Julien Laganier <[email-masked]>
Date: Tue, 13 May 2008 10:09:46 +0200

On Friday 09 May 2008, Alexandru Petrescu wrote:
> Alper Yegin wrote:
> > Hi Alex,
> >
> > The issue at hand is roaming, and identification of realm (as
> > opposed to identification of the host). That's what the realm
> > portion of the NAI is for (in other IETF specs), and that's how it
> > is also used in this spec as well.
> >
> > I hope this clarifies.
>

Alex, do you know Google and/or Wikipedia?

<http://www.google.com/search?q=wikipedia+roaming>

--julien

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 13 May 2008 10:39:29 +0200

Julien Laganier wrote:
>>> portion of the NAI is for (in other IETF specs), and that's how
>>> it is also used in this spec as well.
>>> 
>>> I hope this clarifies.

Ignoring the redirection... Neither Google nor Wikipedia existed when
'Roaming' implementations where described 25 September 1996
draft-aboba-roam-rev which became RFC2194 "Review of Roaming
Implementations".

That roaming does not use Mobile IP.

And why does 'Roaming' need continuous sessions and reachability at a
permanent home address?

Alex

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 13 May 2008 11:40:51 +0300

Alex,

Roaming is described where NAI is defined -- RFC 4282.

If you see issues let us know. Otherwise let's try to wrap this up. Your
thread seems to be the only one holding up this I-D.

Thank you for your cooperation.

Alper 

> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: Friday, May 09, 2008 11:11 PM
> To: Alper Yegin
> Cc: [email-masked]; [email-masked]; [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 13 May 2008 11:57:36 +0200

Alper - for my clarification about procedure: has hiopt been implemented 
or prototyped or demoed somehow?

It's not my intention to write a thread holding up this I-D.

Alex

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 13 May 2008 14:32:14 +0300

Alex,

Not that I think it is a requirement for this I-D to progress, but note that
both WiMAX and 3GPP2 refer to this specification. 

Alper 

> Sent: Tuesday, May 13, 2008 12:58 PM
> To: Alper Yegin
> >>> identification of the host). That's what the realm portion of the NAI
> is
> >> for
> >>>> plus time, 2 - vendor-assigned unique id based on enterprise number,
> 3
> >> -
> >>>> link-layer address).
> >>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 13 May 2008 13:49:08 +0200

Alper Yegin wrote:
> Alex,
> 
> Not that I think it is a requirement for this I-D to progress, but
> note that both WiMAX and 3GPP2 refer to this specification.

Alper - thanks for the clarification.  Then the other question deserves
commenting: what is the IPR context for this specification?

Alex

> 
> Alper
> 
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:[email-masked]] Sent: Tuesday, May 13, 2008
>> 12:58 PM To: Alper Yegin Cc: [email-masked];
>> [email-masked]; [email-masked] Subject: Re: [MEXT] why having
>> DHCP do DNS resolution? (was: FW: Summary for the changes in
>> hiopt-13)
>> 
>> Alper - for my clarification about procedure: has hiopt been
>> implemented or prototyped or demoed somehow?
>> 
>>> If you see issues let us know. Otherwise let's try to wrap this
>>> up. Your thread seems to be the only one holding up this I-D.
>>> 
>>>> -----Original Message----- From: Alexandru Petrescu
>>>> [mailto:[email-masked]] Sent: Friday, May 09,
>>>> 2008 11:11 PM To: Alper Yegin Cc: [email-masked];
>>>> [email-masked]; [email-masked] Subject: Re: [MEXT] why having
>>>> DHCP do DNS resolution? (was: FW:
>> Summary
>>>>> opposed
>> to
>>>>> (in other IETF specs), and that's how it is also used in this
>>>>> spec as
>>>> well.
>>>>> I hope this clarifies.
>>>>> Alper Samsung
>>>>>> -----Original Message----- From: [email-masked]
>>>>>> [mailto:[email-masked]] On Behalf
>> Of
>>>>>> Alexandru Petrescu Sent: Wednesday, April 30, 2008 12:41 PM
>>>>>>  To: [email-masked] Cc: [email-masked];
>>>>>> [email-masked] Subject: Re: [MEXT] why having DHCP do DNS
>>>>>> resolution? (was: FW:
>>>> Summary
>>>>>>> ps> I'm supposed to have a vacation till next Monday, and
>>>>>>> cannot access my samsung account. So kindly refer my
>>>>>>> gmail account as well.
>>>>>>>> Then I don't see why stateless DHCPv6 is needed for
>>>>>>>> this?  Plain full DHCPv6 can accommodate this scenario.
>>>>>>>> 
>>>>>>> Basically plain (stateful) DHCPv6 is used for address
>>>>>>> configuration while stateless DHCPv6 is for other
>>>>>>> parameters configuration such as DNS server address. So
>>>>>>> this HN information should be delivered through stateless
>>>>>>> DHCPv6.
>>>>>> Why does a hiopt MN need to include a Home Network
>>>>>> Identifier (Sub-Opt-Code 1, eg realm of NAI) in the Home
>>>>>> Network Information
>>>> Option
>>>>>> in the Information-Request?  Why isn't it sufficient to use
>>>>>> the
>> Client
>>>>>> Why isn't the DUID enough to identify the Client (1 -
>>>>>> Link-layer
>>>> address
>>>>>> Why is it thought that it is necessary to specify Home
>>>>>> Network Identifier Sub-Opt-Code 1 as being, for example,
>>>>>> the realm part of a NAI, when the DUID exists, is used and
>>>>>> covers a different range of
>>>> cases.
>>>>>>>>>> I think that RFC doesn't suggest the Client to put
>>>>>>>>>> data in a request and the Server to suggest back a
>>>>>>>>>> different data.  Or, apparently, a hiopt-13 Client
>>>>>>>>>> puts  IPv6 home network prefix in a Request, with
>>>>>>>>>> sub-opt-code equal 2, Relay forwards it to Server,
>>>>>>>>>> and Server puts another IPv6 home network prefix in
>>>>>>>>>> a Reply, apparently. Is this the intended hiop-13
>>>>>>>>>> behaviour?
>>>>>>>>>> 
>>>>>>>>>> Is this behaviour in this sense completely
>>>>>>>>>> different than the typical
>>>>>>>>>> 
>>>>>>>>>> DHCPv6 operation?
>>>>>>>>> Section 3.3 says
>>>>>>>>> 
>>>>>>>>> " While the Sub-opt-code 1 is only available in both
>>>>>>>>> the requesting and the returned Home Network
>>>>>>>>> Information options, Sub-opt-codes 2, 3, 4, and 5 are
>>>>>>>>> available only in the returned Home Network
>>>>>>>>> Information option and the MIP6 Relay Agent option."
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Section 4.1 says
>>>>>>>>> 
>>>>>>>>> "  A value of 1 is the only Sub-opt-code available in
>>>>>>>>> the request."
>>>>>> Right, now makes better sense.  For easing my humble
>>>>>> reading this statement could appear in section 3.1 where
>>>>>> the message encoding of
>>>> Home
>>>>>>>>> An MN cannot carry sub-opt-codes other than 1. This
>>>>>>>>> means that a sub-option in the request is used only
>>>>>>>>> to carry the MN's prefered target MSP in case of
>>>>>>>>> id-type 1 so that the server can reply the matching
>>>>>>>>> HA information.
>>>>>>>>> 
>>>>>>>> Right, thanks, now I understand it better as being the
>>>>>>>> basic hiopt behaviour.
>>>>>>>> 
>>>>>>>> Let me agree with you for a short while that it's good
>>>>>>>> to identify the subnet by a FQDN.
>>>>>>>> 
>>>>>>>> If so basically MN (DHCP Client) puts FQDN in the
>>>>>>>> request and the DHCP Server sends back an IP address of
>>>>>>>> the Home Agent.
>>>>>>>> 
>>>>>>>> How is this different than DNS Resolution?  Why do we
>>>>>>>> need DHCP to do DNS Resolution?
>>>>>>> While MNs are required to know an exact FQDN of the
>>>>>>> target (HA) for DNS resolution, DHCP discovery enables HA
>>>>>>> discovery in variable ways even in case MN does not have
>>>>>>> exact information about its home network. For e.g. it can
>>>>>>> request the local HAs with the id-type 0.
>> Or
>>>>>>> the server may return partially matching HA information
>>>>>>> as
>> described
>>>>>>> in Section 4.3.
>>>>>> The really big problem here - and in all bootstrapping
>>>>>> documents - is that we have not precisely described what is
>>>>>> the information
>> available
>>>>>> at the MN prior to bootstrapping phase.  Different
>>>>>> documents make different assumptions and they overlap.
>>>>>> 
>>>>>>> IMHO, such a load-balancing approach is wellknown and
>>>>>>> does not need to be limited to VPN. Anyway here the key
>>>>>>> point is "to provide HA information based on NAI" can be
>>>>>>> implemented in various ways as
>> least
>>>>>> If it is the key point then it should be much more clear
>>>>>> than that. It is far from being clear.  Now here it's said
>>>>>> "NAI" but in the document it's said "for example, the realm
>>>>>> part of NAI".  If we
>> decide
>>>>>> to do only NAI-based HA address bootstrapping with DHCPv6
>>>>>> then I can agree we can have a better document.
>>>>>> 
>>>>>> That is a big if.
>>>>>> 
>>>>>> Because - does DHCPv6 or DHCPv4 ever use NAI for address
>>>>>> allocation
>> or
>>>>>> parameter configuration?  I don't think so.  They use MAC
>>>>>> address (or DUID) but not NAI.  I find hiopt very much
>>>>>> different than DHCPv6 in
>>>> this
>>>>>> sense.  IMHO. ?.
>>>>>> 
>>>>>> If one wants to use NAI (or its realm part) to find the
>>>>>> corresponding
>>>> IP
>>>>>> This email has been scanned by the MessageLabs Email
>>>>>> Security System. For more information please visit
>>>>>> http://www.messagelabs.com/email
>>>>>> 
>>>>>> _______________________________________________ MEXT
>>>>>> mailing list [email-masked] 
>>>>  This email has been scanned by the MessageLabs Email Security
>>>> System. For more information please visit
>>>> http://www.messagelabs.com/email 
>>  This email has been scanned by the MessageLabs Email Security
>> System. For more information please visit
>> http://www.messagelabs.com/email

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 13 May 2008 15:37:11 +0300

I can only answer this for myself. I am not aware of any IPRs on this I-D.

Alper
Samsung 

> Sent: Tuesday, May 13, 2008 2:49 PM
> To: Alper Yegin

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 13 May 2008 16:15:12 +0200

> I can only answer this for myself. I am not aware of any IPRs on this

Alper - thanks for the clarifications.

Let me summarize:  one thinks there's no IPR on the doc, the document
was not prototyped/implemented, the document is being referred by 3GPP2
and by WiMax, and technically there appears to be some miscomprehension
from me about the use of NAI to discover a HA with DHCP (as opposed to
using a DUID).

In this context, do you think the document should be progressed on the
Standards Track?

In my experience, I recognize this situation as a typical situation
which would progress a draft on the Informational track.

I hope this clarifies my part of it.  I will let other WG members
express about the hiopt situation - what do other people think?

Alex

>> 2:49 PM To: Alper Yegin Cc: [email-masked]; 
>>> Not that I think it is a requirement for this I-D to progress, 
>>> but note that both WiMAX and 3GPP2 refer to this specification.
>> Alper - thanks for the clarification.  Then the other question 
>> deserves commenting: what is the IPR context for this 
>> specification?
>> 
>> Alex
>> 
>>> Alper
>>> 
>>>> [mailto:[email-masked]] Sent: Tuesday, May 13, 
>>>> 2008 12:58 PM To: Alper Yegin Cc: [email-masked]; 
>>>>> If you see issues let us know. Otherwise let's try to wrap 
>>>>> this up. Your thread seems to be the only one holding up this
>>>>>  I-D.
>>>>> 
>>>>>>  [email-masked]; [email-masked] Subject: Re: [MEXT] why 
>>>>>> having DHCP do DNS resolution? (was: FW:
>>>> Summary
>>>>>>> The issue at hand is roaming, and identification of realm
>>>>>>>  (as opposed
>>>> to
>>>>>>> (in other IETF specs), and that's how it is also used in 
>>>>>>> this spec as
>>>>>> well.
>>>>>>> I hope this clarifies.
>>>>>>>> Alexandru Petrescu Sent: Wednesday, April 30, 2008 
>>>>>>>> 12:41 PM To: [email-masked] Cc: 
>>>>>>>> [email-masked]; [email-masked] Subject: Re: [MEXT] 
>>>>>>>> why having DHCP do DNS resolution? (was: FW:
>>>>>> Summary
>>>>>>>>> ps> I'm supposed to have a vacation till next Monday,
>>>>>>>>>  and cannot access my samsung account. So kindly
>>>>>>>>> refer my gmail account as well.
>>>>>>>>> parameters configuration such as DNS server address. 
>>>>>>>>> So this HN information should be delivered through 
>>>>>>>>> stateless DHCPv6.
>>>>>>>> Identifier (Sub-Opt-Code 1, eg realm of NAI) in the 
>>>>>>>> Home Network Information
>>>>>> Option
>>>>>>>> in the Information-Request?  Why isn't it sufficient to
>>>>>>>>  use the
>>>> Client
>>>>>>>>  Network Identifier Sub-Opt-Code 1 as being, for 
>>>>>>>> example, the realm part of a NAI, when the DUID exists,
>>>>>>>>  is used and covers a different range of
>>>>>> cases.
>>>>>>>>>>>> I think that RFC doesn't suggest the Client to 
>>>>>>>>>>>> put data in a request and the Server to suggest
>>>>>>>>>>>>  back a different data.  Or, apparently, a 
>>>>>>>>>>>> hiopt-13 Client puts  IPv6 home network prefix 
>>>>>>>>>>>> in a Request, with sub-opt-code equal 2, Relay 
>>>>>>>>>>>> forwards it to Server, and Server puts another 
>>>>>>>>>>>> IPv6 home network prefix in a Reply, 
>>>>>>>>>>>> apparently. Is this the intended hiop-13 
>>>>>>>>>>>> behaviour?
>>>>>>>>>>>> 
>>>>>>>>>>> " While the Sub-opt-code 1 is only available in 
>>>>>>>>>>> both the requesting and the returned Home Network
>>>>>>>>>>>  Information options, Sub-opt-codes 2, 3, 4, and 
>>>>>>>>>>> 5 are available only in the returned Home Network
>>>>>>>>>>> "  A value of 1 is the only Sub-opt-code 
>>>>>>>>>>> available in the request."
>>>>>>>> reading this statement could appear in section 3.1 
>>>>>>>> where the message encoding of
>>>>>> Home
>>>>>>>>>>> An MN cannot carry sub-opt-codes other than 1. 
>>>>>>>>>>> This means that a sub-option in the request is 
>>>>>>>>>>> used only to carry the MN's prefered target MSP 
>>>>>>>>>>> in case of id-type 1 so that the server can reply
>>>>>>>>>>>  the matching HA information.
>>>>>>>>>>> 
>>>>>>>>>> Right, thanks, now I understand it better as being 
>>>>>>>>>> the basic hiopt behaviour.
>>>>>>>>>> 
>>>>>>>>>> Let me agree with you for a short while that it's 
>>>>>>>>>> good to identify the subnet by a FQDN.
>>>>>>>>>> 
>>>>>>>>>> request and the DHCP Server sends back an IP 
>>>>>>>>>> address of the Home Agent.
>>>>>>>>>> 
>>>>>>>>>> How is this different than DNS Resolution?  Why do 
>>>>>>>>>> we need DHCP to do DNS Resolution?
>>>>>>>>> target (HA) for DNS resolution, DHCP discovery 
>>>>>>>>> enables HA discovery in variable ways even in case MN
>>>>>>>>>  does not have exact information about its home 
>>>>>>>>> network. For e.g. it can request the local HAs with 
>>>>>>>>> the id-type 0.
>>>> Or
>>>>>>>>> the server may return partially matching HA 
>>>>>>>>> information as
>>>> described
>>>>>>>>> in Section 4.3.
>>>>>>>>  documents - is that we have not precisely described 
>>>>>>>> what is the information
>>>> available
>>>>>>>>>  does not need to be limited to VPN. Anyway here the 
>>>>>>>>> key point is "to provide HA information based on NAI"
>>>>>>>>>  can be implemented in various ways as
>>>> least
>>>>>>>> If it is the key point then it should be much more 
>>>>>>>> clear than that. It is far from being clear.  Now here 
>>>>>>>> it's said "NAI" but in the document it's said "for 
>>>>>>>> example, the realm part of NAI".  If we
>>>> decide
>>>>>>>> to do only NAI-based HA address bootstrapping with 
>>>>>>>> DHCPv6 then I can agree we can have a better document.
>>>>>>>> 
>>>>>>>> That is a big if.
>>>>>>>> 
>>>>>>>> Because - does DHCPv6 or DHCPv4 ever use NAI for 
>>>>>>>> address allocation
>>>> or
>>>>>>>> parameter configuration?  I don't think so.  They use 
>>>>>>>> MAC address (or DUID) but not NAI.  I find hiopt very 
>>>>>>>> much different than DHCPv6 in
>>>>>> this
>>>>>>>> sense.  IMHO. ?.
>>>>>>>>

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 13 May 2008 09:29:50 -0500

Alex,

There is no requirement for an I-D to have implementations in order for it
to be progressed as a standards track RFC (Proposed standard). To get to
draft standard, we need to show implementations (multiple) and also interop
results. 

Use of DHCP (options) to obtain an HA address is a valid approach and hence
I do not see any reason why this should be an informational document.
The DHCP options being specified in this I-D IMO should be specified by the
IETF as a proposed standard.

-Raj

---

From: Julien Laganier <[email-masked]>
Date: Tue, 13 May 2008 17:19:04 +0200

On Tuesday 13 May 2008, Alexandru Petrescu wrote:
> was not prototyped/implemented, the document is being referred by
> 3GPP2 and by WiMax, and technically there appears to be some
> miscomprehension from me about the use of NAI to discover a HA with
> DHCP (as opposed to using a DUID).
>
> In this context, do you think the document should be progressed on
> the Standards Track?
>

Alex,

As a working group chair I'd like to suggest that we conclude this 
discussion now. The MIP6 WG was chartered to publish as a proposed 
standard a specification for "DHCP Options for Home Information 
Discovery in MIPv6". Thus it's not longer time to discuss whether such 
a specification shall be informational.

Thanks in advance for your understanding.

--julien