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

[Ryuji Wakikawa <[e-mail]>]

Hi Vijay,

On 2009/04/10, at 1:30, Vijay Devarapalli wrote:

> 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

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

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

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

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

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

>
>
> Vijay
>
>>
>> Thanks,
>> Vidya
>>
>>> -----Original Message-----
>>> From: Vijay Devarapalli [mailto:[e-mail]]
>>> Sent: Thursday, April 09, 2009 2:57 PM
>>> To: Narayanan, Vidya; Sri Gundavelli; Soininen, Jonne (NSN
>> - FI/Espoo)
>>> Cc: [e-mail]
>>> Subject: Re: [netlmm] IPR Concerns on the use of DHCP Server
>>> Identifier Override Sub-option
>>>
>>> Hi Vidya,
>>>
>>> On 4/9/09 1:16 AM, "Narayanan, Vidya" wrote:
>>>
>>>> <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?
>>>
>>> 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
>>>
>>>> Also, I'd like to hear other opinions on this topic, if
>> any, as well.
>>>>
>>>> Thanks,
>>>> Vidya
>>>>
>>>>> -----Original Message-----
>>>>> From: [e-mail]
>> [mailto:[e-mail]] On
>>>>> Behalf Of Sri Gundavelli
>>>>> Sent: Wednesday, April 08, 2009 12:25 AM
>>>>> To: Soininen, Jonne (NSN - FI/Espoo)
>>>>> Cc: [e-mail]
>>>>> Subject: Re: [netlmm] IPR Concerns on the use of DHCP Server
>>> Identifier
>>>>> Override Sub-option
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, 8 Apr 2009, Soininen, Jonne (NSN - FI/Espoo) wrote:
>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>> On 4/1/09 9:59 PM, "Basavaraj Patil" <[e-mail]>
>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>> On 3/26/09 2:07 PM, "ext Vijay Devarapalli"
>> <[e-mail]>
>>>>> 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
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> netlmm mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>
>>>>>> --
>>>>>> Jonne Soininen
>>>>>> Nokia Siemens Networks
>>>>>>
>>>>>> Tel: [phone]
>>>>>> E-mail: [e-mail]
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> netlmm mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>
>>>>> _______________________________________________
>>>>> netlmm mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>> _______________________________________________
>>>> netlmm mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>
>>
> _______________________________________________
> netlmm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netlmm