Subject: Re: [netlmm] IPR Concerns on the use of DHCP Server Identifier Override Sub-option

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 01 Apr 2009 11:29:34 -0700

Hi Joel,

Joel Hortelius wrote:
> Hi Vijay;
> 
> Well, I may very well be the one missing something here. Probably too
> focused on my own implementation details. Using the [HoA,
> ClientID/HwAddr(which I assume is what you call the mobile node id?)]
> would be a unique key for the lease, granted. However, when having
> identical private space routing domains, routing information quickly
> becomes ambigous. The LMA can determine forwarding based on receiving
> interface or GRE keys. When applications located on the LMA itself
> attempts to send traffic(such as the co-located DHCP server) to the
> private space addresses, the destination will be ambigous. The
> co-located DHCP server would have to be able to retrieve the tunneling
> information from the LMA, or it would not be able to send the reply
> correctly using the correct GRE keys allowing the MAG to forward it to
> the correct node. 

I think it is dangerous to have the DHCP server function on the LMA can 
do the routing, i.e., figure out which MAG to tunnel the DHCP packet to. 
It should be the proxy binding cache and the forwarding entries on the 
LMA which would decide how the packet would get to the mobile node. The 
DHCP server function should construct the reply and have the LMA tunnel 
the packet to the right MAG. There could even be a NAT on the path 
between the MAG and the LMA. In this case, the DHCP server function, if 
it is doing the tunneling, also has to take into account UDP 
encapsulation and the right port numbers.

Vijay

 > It does add complexity and higher demands on
> integration between the modules, but not impossible to do. I find it
> cleaner to have the functions separated; but as I said, since its doable
> and perhaps a rather obscure setup, I'll not argue.
> 
> Regards,
> Joel Hortelius
> 
> 
> On Mon, 2009-03-30 at 16:50 -0700, Vijay Devarapalli wrote:
>> Hi Joel,
>>
>> Joel Hortelius wrote:
>>> Hi Vijay;
>>>
>>> It pretty much depends on how complex scenarios the spec is supposed to
>>> handle. For example, the setup scenario in the GRE key draft, section
>>> 3.1 would be difficult to solve with the DHCP relay without using the
>>> server override, since forwarding the DHCP reply without the agent
>>> information would be ambigous given that two nodes have the same v4 hoa
>>> (granted, even if you add the remote id you dont have enough forwarding
>>> information, but you can add extra information such as the relay agent
>>> link-selection sub opt to solve it).
>> For the initial DHCP messages, the MAG as a DHCP relay is required to 
>> add the DHCP relay agent information option. This would allow the LMA to 
>> distinguish between two different requests.
>>
>> For subsequent renewal of the IPv4 address, the LMA just needs to check 
>> the mobile node identity against the IPv4 address it allocated earlier 
>> when it receives a DHCPREQUEST for renewal directly from the mobile 
>> node. It shouldn't matter if two different mobile nodes have the same 
>> private IPv4 home address. Right?
>>
>> What am I missing?
>>
>> Vijay
>>
>>> Regards,
>>> Joel Hortelius
>>>
>>> On Thu, 2009-03-26 at 15:07 -0400, Vijay Devarapalli wrote:
>>>> Hello all,
>>>>
>>>> I have concerns about using the DHCP Server Identifier Override
>>>> Sub-option in draft-ietf-netlmm-pmip6-ipv4-support-10. The DHCP Server
>>>> Identifier Override Sub-option is defined in RFC 5107. RFC 5107 has a
>>>> Cisco IPR.
>>>>
>>>> This DHCP option basically allows the MAG, in the DHCP relay scenario,
>>>> to force itself to be on the path for subsequent DHCP messages sent to
>>>> the LMA after the initial session setup. I don't believe this is
>>>> required. 
>>>>
>>>> The draft currently does say it is optional to use this. Sri and I have
>>>> been discussion this for nearly 6 months now. The earlier versions of
>>>> the document said this is required to be implemented by the MAG. But
>>>> after offline and mailing list discussions, it turned out that it is not
>>>> really required on the MAG. So now it has been made optional.
>>>>
>>>> But there is still a basic question on why use this option at all.
>>>> That's not clear to me. My suggestion is to remove the reference to RFC
>>>> 5107 in draft-ietf-netlmm-pmip6-ipv4-support-10. If there are folks
>>>> still interested in implementing this option and using it with PMIPv6,
>>>> it would perhaps better if this is described in a separate document.
>>>>
>>>> Sri and I have already discussed this quite a bit. I would like to hear
>>>> other opinions.
>>>>
>>>> Vijay
>>>> _______________________________________________
>>>> netlmm mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>
>>
>

---

From: <[email-masked]>
Date: Wed, 1 Apr 2009 20:59:12 +0200

I am not too concerned about the IPR aspects mentioned in your mail.

But lets discuss more this DHCP option.
If the DHCP server is at the LMA (or elsewhere), the MN is able to
send/receive DHCP messages using the DHCP servers unicast address. However
all of the MNs packets are always going through the MAG. So having DHCP
messages go through the relay at the MAG is not a concern, is it?
I agree that there is no reason for the DHCP messages between the MN and
DHCP server to be forced to pass through the relay because it does not serve
any specific purpose in the PMIP6 context.
If that is indeed the case, why include this DHCP option at all in the I-D.
I don't see a case for it being optional either.

So unless someone can provide a good use case for why this DHCP option is
needed in PMIP6, I don't see a reason for it being in the I-D.

-Raj

---

From: Joel Hortelius <[email-masked]>
Date: Thu, 02 Apr 2009 08:57:17 +0000

Well, 

Regardless of whether the DHCP server extracts the binding information,
a mechanism is provided to "insert" it into the correct forwarding entry
in the data plane or given to the LMA process for forwarding, it still
does require additional implementation specific APIs between the DHCP
functionality and the LMA. As I said, I'm not arguing it can't be done.
I'm saying it gets hairy. Using the DHCP option server ID makes it clean
and straightforward, solving the issue using already existing mechanisms
in a well-tried protocol. If the Cisco IPR makes this solution out-of
bounds, or the issue itself is out-of-scope for this doc, then so be
it. 

Regards,
Joel Hortelius

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 2 Apr 2009 12:36:38 -0400

Ok, the point I am tryign to make is that, irrespective of what other
function is co-located with the LMA, tunneling of any packet to the MAG
meant for the mobile node should be done the LMA. The other co-located
functions on the LMA should not try to figure out how to tunnel the
packet to the MAG.

This does not require any API between the co-located DHCP function and
the LMA function.

Vijay

> -----Original Message-----
> From: Joel Hortelius [mailto:[email-masked]] 
> Sent: Thursday, April 02, 2009 1:57 AM
> To: Vijay Devarapalli
> Cc: [email-masked]
> Subject: Re: [netlmm] IPR Concerns on the use of DHCP Server 
> Identifier Override Sub-option
> 
> Well, 
> 
> Regardless of whether the DHCP server extracts the binding 
> information, a mechanism is provided to "insert" it into the 
> correct forwarding entry in the data plane or given to the 
> LMA process for forwarding, it still does require additional 
> implementation specific APIs between the DHCP functionality 
> and the LMA. As I said, I'm not arguing it can't be done.
> I'm saying it gets hairy. Using the DHCP option server ID 
> makes it clean and straightforward, solving the issue using 
> already existing mechanisms in a well-tried protocol. If the 
> Cisco IPR makes this solution out-of bounds, or the issue 
> itself is out-of-scope for this doc, then so be it. 
> 
> Regards,
> Joel Hortelius
> 
> > > Well, I may very well be the one missing something here. Probably 
> > > too focused on my own implementation details. Using the [HoA, 
> > > ClientID/HwAddr(which I assume is what you call the mobile node 
> > > id?)] would be a unique key for the lease, granted. However, when 
> > > having identical private space routing domains, routing 
> information 
> > > quickly becomes ambigous. The LMA can determine 
> forwarding based on 
> > > receiving interface or GRE keys. When applications located on the 
> > > LMA itself attempts to send traffic(such as the co-located DHCP 
> > > server) to the private space addresses, the destination will be 
> > > ambigous. The co-located DHCP server would have to be able to 
> > > retrieve the tunneling information from the LMA, or it 
> would not be 
> > > able to send the reply correctly using the correct GRE 
> keys allowing 
> > > the MAG to forward it to the correct node.
> > 
> > I think it is dangerous to have the DHCP server function on the LMA 
> > can do the routing, i.e., figure out which MAG to tunnel 
> the DHCP packet to.
> > LMA which would decide how the packet would get to the mobile node. 
> > The DHCP server function should construct the reply and 
> have the LMA 
> > tunnel the packet to the right MAG. There could even be a 
> NAT on the 
> > path between the MAG and the LMA. In this case, the DHCP server 
> > function, if it is doing the tunneling, also has to take 
> into account 
> > UDP encapsulation and the right port numbers.
> > 
> > Vijay
> > 
> > > cleaner to have the functions separated; but as I said, since its 
> > > doable and perhaps a rather obscure setup, I'll not argue.
> > > 
> > > Regards,
> > > Joel Hortelius
> > > 
> > > 
> > >>> It pretty much depends on how complex scenarios the spec is 
> > >>> supposed to handle. For example, the setup scenario in 
> the GRE key 
> > >>> draft, section
> > >>> 3.1 would be difficult to solve with the DHCP relay 
> without using 
> > >>> the server override, since forwarding the DHCP reply 
> without the 
> > >>> agent information would be ambigous given that two 
> nodes have the 
> > >>> same v4 hoa (granted, even if you add the remote id you 
> dont have 
> > >>> enough forwarding information, but you can add extra 
> information 
> > >>> such as the relay agent link-selection sub opt to solve it).
> > >> For the initial DHCP messages, the MAG as a DHCP relay 
> is required 
> > >> to add the DHCP relay agent information option. This would allow 
> > >> the LMA to distinguish between two different requests.
> > >>
> > >> For subsequent renewal of the IPv4 address, the LMA just 
> needs to 
> > >> check the mobile node identity against the IPv4 address it 
> > >> allocated earlier when it receives a DHCPREQUEST for renewal 
> > >> directly from the mobile node. It shouldn't matter if 
> two different 
> > >> mobile nodes have the same private IPv4 home address. Right?
> > >>
> > >> What am I missing?
> > >>
> > >> Vijay
> > >>
> > >>> Regards,
> > >>> Joel Hortelius
> > >>>
> > >>>> Sub-option in draft-ietf-netlmm-pmip6-ipv4-support-10. 
> The DHCP 
> > >>>> Server Identifier Override Sub-option is defined in 
> RFC 5107. RFC 
> > >>>> 5107 has a Cisco IPR.
> > >>>>
> > >>>> This DHCP option basically allows the MAG, in the DHCP relay 
> > >>>> scenario, to force itself to be on the path for 
> subsequent DHCP 
> > >>>> messages sent to the LMA after the initial session 
> setup. I don't 
> > >>>> believe this is required.
> > >>>>
> > >>>> The draft currently does say it is optional to use 
> this. Sri and 
> > >>>> I have been discussion this for nearly 6 months now. 
> The earlier 
> > >>>> versions of the document said this is required to be 
> implemented 
> > >>>> by the MAG. But after offline and mailing list discussions, it 
> > >>>> turned out that it is not really required on the MAG. 
> So now it has been made optional.
> > >>>>
> > >>>> That's not clear to me. My suggestion is to remove the 
> reference 
> > >>>> to RFC
> > >>>> 5107 in draft-ietf-netlmm-pmip6-ipv4-support-10. If there are 
> > >>>> folks still interested in implementing this option and 
> using it 
> > >>>> with PMIPv6, it would perhaps better if this is 
> described in a separate document.
> > >>>>
> > >>>> Sri and I have already discussed this quite a bit. I 
> would like 
> > >>>> to hear other opinions.
> > >>>>
> > >>>> Vijay

---

From: "Soininen, Jonne (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 08 Apr 2009 09:20:00 +0300

Hello everybody,

As a chair or a private person, I'm not really too concerned about the IPR
issue as long as the IPR is declared in the proper manner according the IETF
rules.

However, I wonder if we really have to have functions in the drafts that
seem to bring nothing but complexity. So, I think this should be taken away
unless somebody can really show that there is a use for it.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 8 Apr 2009 00:24:52 -0700 (PDT)

Sorry, did not follow up on this thread.

Couple of points:

The draft talked about the potential ways for the MAG to monitor the
DHCP interactions between the mobile and the LMA. The MAG can
intercept all DHCP packets or register itself in the path.

So, why we want the MAG to be in path for DHCP flows ? There are two
signaling planes, one based on DHCP between the LMA/DHCP server and the 
MN, the other based on PMIP signaling between LMA and MAG. We want the
PMIP entities to allocate the address for the mobil node, set up the
forwarding, while we expect the LMA to directly deliver the address over
DHCP to the mobile node. We need some coordination between these entities,
we dont want one set of entities to assume one state and while the other
entities use some other state. We need to tie these flows.

In a proxy model, where the MAG is performing certain functions on
behalf of a mobile, it is required to ensure its in path for these
control flows. If the mobile node releases the address or extends it,
it can ensure it has the right state. So, if the MAG can be in path by
including the DHCP Server Id option, it helps.

This is an optional mechanism, presented in an informative text. Its
certainly not listed, because there is an IPR on it. IPR argument is base
less. So far we have not taken any technical decisions based on if there
is an IPR, or who holds it. We should not get into IPR discussions, thats
not my job or expertise. If I take that approach, I can as well rip apart
any text in any document.

Ryuji and me had extensive discussions with Vijay on this and obviosuly
that did not converge. But, as usual I spent 90% of my time debating with
Vijay one some optional mechanisms and 10% on writing the actual draft :),
on a lighter note.

Also, please see the comments from Joel Hortelius, as I read it, he also
thinks its cleaner to use that option.

The entire DHCP text is non-normative, clearly presented as a potential
approach that can be adopted. I dont know, how this should be an issue
on some informative text. I dont have an answer to Vijay's comment that
without using the MUST/SHOULD, one can still make the text normative. May
be the IETF process experts can comment on this.

RFC-5103 is an IETF standard. We are referencing a document, which is a 
standards track document, standardized by IETF.

This is not introducing any complexity, rather  building integrity into
the protocol states across various entities.

Regards
Sri

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 9 Apr 2009 01:16:33 -0700

<Co-chair hat on>

Sri,

> So far we have not taken any technical decisions based on if
> there
> is an IPR, or who holds it.

The WG can, at any time, debate whether or not to include a particular piece of technology in an RFC based on the IPR involved.  It is ultimately a WG decision to determine whether the technical merits of the solution surpass the IPR encumbrances that come with it.  And, it does not actually matter that the IPR encumbered solution is another RFC.  So, let's try to find a solution to the problem raised in a manner that satisfies the WG. 

Vijay,
Are you concerned about even optionally having this in the document given the IPR status?  If so, could you please elaborate on the concerns itself a bit more?  Are you saying that it works equally well even without this option or that it can be made to work without it even if slightly suboptimal? I think it would be good for the WG to understand this tradeoff.  

Also, I'd like to hear other opinions on this topic, if any, as well. 

Thanks,
Vidya

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Sri Gundavelli
> Sent: Wednesday, April 08, 2009 12:25 AM
> To: Soininen, Jonne (NSN - FI/Espoo)
> Cc: [email-masked]
> Subject: Re: [netlmm] IPR Concerns on the use of DHCP Server Identifier
> Override Sub-option
> 
> scenario,

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 09 Apr 2009 14:57:02 -0700

Hi Vidya,

On 4/9/09 1:16 AM, "Narayanan, Vidya" wrote:

> The WG can, at any time, debate whether or not to include a particular piece
> of technology in an RFC based on the IPR involved.  It is ultimately a WG
> decision to determine whether the technical merits of the solution surpass the
> IPR encumbrances that come with it.  And, it does not actually matter that the
> IPR encumbered solution is another RFC.  So, let's try to find a solution to
> the problem raised in a manner that satisfies the WG.
> 
> Vijay,
> Are you concerned about even optionally having this in the document given the
> IPR status?  If so, could you please elaborate on the concerns itself a bit
> more?  

The entire DHCP section was completely re-written a few versions ago.
The text that went into the re-written DHCP section was not discussed on the
mailing list before it was added to the document. The new text had a number
of options for pretty much very configuration. I have been discussing with
Sri for the past 5 months or so removing the options and simplifying the
text wherever possible.

Frankly, I don't see the point in having an optional mechanism described in
the document. Especially when this optional mechanism has an IPR.

> Are you saying that it works equally well even without this option or
> that it can be made to work without it even if slightly suboptimal? I think it
> would be good for the WG to understand this tradeoff.

IMO, it works equally well without it.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 09 Apr 2009 15:04:00 -0700

Hi Sri,

> Vijay one some optional mechanisms and 10% on writing the actual draft :),

This could have been avoided if the DHCP related changes had been first
posted on the mailing list, agreed upon and then added to the draft. Instead
you just completely re-wrote the DHCP section based on some offline
discussions and submitted a new version.  The new DHCP text had numerous
options for pretty much every configuration. Fortunately, we have simplified
it quite a bit already.

> thinks its cleaner to use that option.

I hope you also saw the subsequent emails that were exchanged on this.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 9 Apr 2009 15:30:30 -0700 (PDT)

Vijay,

> Sri for the past 5 months or so removing the options and simplifying the

The document that went through the WG last call and what we have
today is almost same, other than the fixes suggested in the AD
and external reviews. So, these two lines on MAG adding that
DHCP option is not a recent change.

> IMO, it works equally well without it.

With out that the MAG needs to look at all DHCP packets,
as supposed to registering itself in path. If some
implementation wants to use this option and be in path,
what is the issue you see ? Is the draft forcing that
mechanism ? There are dozen other claims on mobility work
and as such we can probably remove most are all parts of
the drafts. Any case, Ryuji and me are puzzled on what
the issue is in having "BTW, the MAG can also use that
option in the DHCP packet" ?

I've no problem taking this out, if the concern is valid
and if many folks are screaming out on this. Here it is
some informational and that too one optional mechanism,
we are not gaining any thing here. I'm also with the point
that if some IPR we can avoid, sure, we can. But, this is
some informative. Come on, please give a valid reason.

Sri

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 9 Apr 2009 21:12:13 -0700

Vijay,
Do you see substantial text changes that have occurred after WGLC that have not been posted to the list?  Going through the diffs, I am not seeing that, but, please do point out if that is the case and we can go back to determining consensus on the added text.  

Also, could you explain the concerns from an IPR viewpoint - i.e., what about the IPR do you think introduces an issue from the implementation point of view?  

Thanks,
Vidya

> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Thursday, April 09, 2009 2:57 PM
> To: Narayanan, Vidya; Sri Gundavelli; Soininen, Jonne (NSN - FI/Espoo)
> Cc: [email-masked]
> >> Vijay one some optional mechanisms and 10% on writing the actual
> draft
> >> :),
> >> on a lighter note.
> >>
> >> without using the MUST/SHOULD, one can still make the text
> normative.
> >> May
> >>>> I agree that there is no reason for the DHCP messages between the
> MN
> >> and
> >>>>> Identifier Override Sub-option is defined in RFC 5107. RFC 5107
> has
> >> a
> >>>>> Cisco IPR.
> >>>>>
> >>>>> to force itself to be on the path for subsequent DHCP messages
> sent
> >> to
> >>>>> The draft currently does say it is optional to use this. Sri and
> I
> >> have
> >>>>> been discussion this for nearly 6 months now. The earlier
> versions
> >> of
> >>>>> That's not clear to me. My suggestion is to remove the reference
> to
> >> RFC
> folks
> >>>>> Sri and I have already discussed this quite a bit. I would like
> to
> >> hear
> >>>>> other opinions.
> >>>>>
> >>>>> Vijay

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 10 Apr 2009 01:30:29 -0400

Hi Vidya, 

> Do you see substantial text changes that have occurred after 
> WGLC that have not been posted to the list?  Going through 
> the diffs, I am not seeing that, but, please do point out if 
> that is the case and we can go back to determining consensus 
> on the added text.  

The substantial DHCP changes I was referring to was done in one of the
earlier versions before the WG last call. I think it was version 4. The
changes that were introduced without WG discussion were

- Three different options for configuring the DHCP server IP address in
the proxy model 
- Three different options for handling IPv4 home address renewal with a
different DHCP server after a handover
- A requirement on the MAG to intercept DHCP renew messages from the MN
in the DHCP relay model
- Two different mechanisms for the MAG to intercept the DHCP renew
messages from the MN in the DHCP relay model

I don't remember all of them.

Since then, I guess since version 05, we have been having discussions on
the DHCP sections. We have simplified the DHCP section by removing the
following so far

1. Multiple options for configuring the DHCP server IP address in the
proxy model - only one option left where a fixed DHCP address is
configured on all DHCP servers
2. The multiple options for handling IPv4 home address renewal with a
different DHCP server after a handover were completely removed
3. The requirements on the MAG to intercept DHCP renew messages was made
optional

So we have made quite a bit of progress. The current text is quite
simple and straightforward to implement.

> Also, could you explain the concerns from an IPR viewpoint - 
> i.e., what about the IPR do you think introduces an issue 
> from the implementation point of view?  

Since it is optional, I can skip implementing it. But the question is,
why is it there in the document?

Vijay

> > >> So far we have not taken any technical decisions based 
> on if there 
> > > of technology in an RFC based on the IPR involved.  It is 
> ultimately
> > a WG
> > > IPR encumbrances that come with it.  And, it does not actually 
> > > matter
> > that the
> > > Are you concerned about even optionally having this in 
> the document
> > given the
> > > IPR status?  If so, could you please elaborate on the concerns 
> > > itself
> > a bit
> > > more?
> > 
> > The text that went into the re-written DHCP section was not 
> discussed 
> > on the mailing list before it was added to the document. 
> The new text 
> > had a number of options for pretty much very configuration. I have 
> > been discussing with Sri for the past 5 months or so removing the 
> > options and simplifying the text wherever possible.
> > 
> > Frankly, I don't see the point in having an optional mechanism 
> > described in the document. Especially when this optional 
> mechanism has 
> > an IPR.
> > 
> > > Are you saying that it works equally well even without 
> this option 
> > > or that it can be made to work without it even if slightly 
> > > suboptimal? I
> > think it
> > >> The draft talked about the potential ways for the MAG to monitor 
> > >> the DHCP interactions between the mobile and the LMA. 
> The MAG can 
> > >> So, why we want the MAG to be in path for DHCP flows ? There are 
> > >> two signaling planes, one based on DHCP between the 
> LMA/DHCP server 
> > >> and
> > the
> > >> MN, the other based on PMIP signaling between LMA and 
> MAG. We want
> > the
> > >> PMIP entities to allocate the address for the mobil node, set up 
> > >> the forwarding, while we expect the LMA to directly deliver the 
> > >> address over DHCP to the mobile node. We need some coordination 
> > >> between these entities, we dont want one set of entities 
> to assume 
> > >> one state and while the other entities use some other state. We 
> > >> need to tie these flows.
> > >>
> > >> it can ensure it has the right state. So, if the MAG can 
> be in path
> > by
> > >> This is an optional mechanism, presented in an informative text. 
> > >> Its certainly not listed, because there is an IPR on it. IPR 
> > >> argument is base less. So far we have not taken any technical 
> > >> decisions based on if there is an IPR, or who holds it. 
> We should 
> > >> not get into IPR discussions, thats not my job or 
> expertise. If I 
> > >> take that approach, I can as well rip apart any text in any 
> > >> document.
> > >>
> > >> that did not converge. But, as usual I spent 90% of my time 
> > >> debating with Vijay one some optional mechanisms and 10% 
> on writing 
> > >> the actual
> > draft
> > >> :),
> > >> on a lighter note.
> > >>
> > >> Also, please see the comments from Joel Hortelius, as I 
> read it, he 
> > >> also thinks its cleaner to use that option.
> > >>
> > >> on some informative text. I dont have an answer to 
> Vijay's comment
> > that
> > >> RFC-5103 is an IETF standard. We are referencing a 
> document, which
> > is a
> > >> This is not introducing any complexity, rather  building 
> integrity
> > into
> > >>> As a chair or a private person, I'm not really too 
> concerned about
> > >> the IPR
> > >>> issue as long as the IPR is declared in the proper manner 
> > >>> according
> > >> the IETF
> > >>> rules.
> > >>>
> > >>> However, I wonder if we really have to have functions in the 
> > >>> drafts
> > >> that
> > >>>> If the DHCP server is at the LMA (or elsewhere), the 
> MN is able 
> > >>>> to send/receive DHCP messages using the DHCP servers 
> unicast address.
> > >> However
> > >>>> all of the MNs packets are always going through the MAG. So 
> > >>>> having
> > >> DHCP
> > >>>> DHCP server to be forced to pass through the relay because it 
> > >>>> does
> > >> not serve
> > >>>> If that is indeed the case, why include this DHCP 
> option at all 
> > >>>> in
> > >> the I-D.
> > >>>> On 3/26/09 2:07 PM, "ext Vijay Devarapalli" 
> <[email-masked]>
> > >> wrote:
> > >>>>
> > >>>>> Hello all,
> > >>>>>
> > >>>>> Sub-option in 
> draft-ietf-netlmm-pmip6-ipv4-support-10. The DHCP
> > >> Server
> > >>>>> the document said this is required to be implemented 
> by the MAG.
> > >> But
> > >>>>> after offline and mailing list discussions, it turned 
> out that 
> > >>>>> it
> > >> is not

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Fri, 10 Apr 2009 14:45:02 +0900

Hi, all.

Only from the technical view, the DHCP option in the present form would
provide useful hits for deployments. In addition, that is optional and
informative. I disagree with what the DCHP option removes without certain
explanations and agreements from other guys in this WG.

Cheers.

-- 
Internet Management Technology Lab, Sungkyunkwan University.
Jong-Hyouk Lee.

#email: jonghyouk (at) gmail (dot) com
#webpage: http://hurryon.googlepages.com/

---

From: Ryuji Wakikawa <[email-masked]>
Date: Sat, 11 Apr 2009 23:13:02 -0400

Hi Vijay,

> changes that were introduced without WG discussion were

Yes, the reference to RFC5107 was appeared at version 04 (submitted at  
July 14 2008).

> messages from the MN in the DHCP relay model

We had discussion on these topics. See the presentation slide (page 9  
for RFC5107) at the IETF 72.
https://www.ietf.org/proceedings/08jul/slides/netlmm-1.pdf

> why is it there in the document?

Because there is a reason to keep this.
You should reply how do you implement this IPv4 address releasing  
verification
when DHCP-S is located solely in PMIP domain.

regards,
ryuji