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

[Jong-Hyouk Lee <[e-mail]>]

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.

On Fri, Apr 10, 2009 at 2:30 PM, Vijay Devarapalli <[e-mail]>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
>
> - 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
>
> >
> > 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
>



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

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