Re: [Geopriv] What to do about DHCP and the ever changing PIDF as well as HELD features

From: Rosen, Brian ^lt;Brian.Rosen@neustar.biz>
Date: Tue Jul 15 2008 - 11:14:04 EDT

There is no deployment of anything yet, but I do understand there are
plans for some DHCP deployment in some cable systems and enterprises.

You will have to wait another year, or maybe more, to use deployment as
a guide.

Brian

> -----Original Message-----
> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> Sent: Tuesday, July 15, 2008 11:11 AM
> To: Henning Schulzrinne
> Cc: Rosen, Brian; geopriv@ietf.org; James M. Polk
> Subject: Re: [Geopriv] What to do about DHCP and the ever changing
PIDF as
> well as HELD features
>
> I agree with Henning that it will be difficult to come up with a
general
> rule but I also understand the issue Brian raised.
>
> I am actually more concerned about the lack of deployment of the DHCP
> based mechanisms given that they have been finished already some time
ago.
>
> Wouldn't it be interesting to know what is deployed and why some stuff
> isn't deployed? To some extend that relates to the discussion around
> fixing DHCP-geo.
>
>
>
> Henning Schulzrinne wrote:
> > I don't see how there can be a general rule. My guideline would be
> > "general applicability", "low change frequency" and "size". Items
only
> > of interest to niche applications probably don't belong in DHCP or
> > LLDP-MED; things that change more than hourly, probably not; very
> > large information elements don't, either.
> >
> > In general, I think it would be good to make this decision
explicitly,
> > i.e., decide in each case as part of the evaluation process.
> >
> > My general bias, given that all of these are optional, is to make
them
> > available unless there's a good reason not to.
> >
> > Henning
> >
> > On Jul 14, 2008, at 4:15 PM, Rosen, Brian wrote:
> >
> >> Okay, so what is the guidance?
> >>
> >> When is a feature worthy of getting into, say DHCP?
> >>
> >> Whim of the submitter?
> >>
> >> I would argue that if DHCP is intended to be a very simple
mechanism,
> >> then LbyR is not simple and doesn't belong. I would say you are in
an
> >> arms race, and HELD has LbyR and you decided you needed it.
> >>
> >> The document (Internet Draft) for DHCP lbyr is fine; I'm asking
what
> the
> >> guideline for accepting a work item for inclusion in DHCP-as-LCP
ought
> >> to be.
> >>
> >> What makes LbyR be worthy of inclusion, and let's say, -context
not?
> Or
> >> do you plan on proposing a -context equivalent?
> >>
> >> Brian
> >>
> >>> -----Original Message-----
> >>> From: James M. Polk [mailto:jmpolk@cisco.com]
> >>> Sent: Monday, July 14, 2008 3:00 PM
> >>> To: Rosen, Brian; geopriv@ietf.org
> >>> Subject: RE: [Geopriv] What to do about DHCP and the ever changing
> >> PIDF as
> >>> well as HELD features
> >>>
> >>> At 12:58 PM 7/14/2008, Rosen, Brian wrote:
> >>>> We could make an argument that DHCP is a very simple LCP and just
> >>>> because there is some feature in HELD, we SHOULD NOT implement
that
> >>>> feature in DHCP.
> >>>
> >>> I'm with you here
> >>>
> >>>> If we decided this was a good idea, we might not, for example,
decide
> >> to
> >>>> accept several of the more recent proposals for, to give an
example,
> >>>> retrieving an LbyR from DHCP.
> >>>
> >>> I'm not with you here
> >>>
> >>> give that
> >>>
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-lbyr-uri-
> >>> option-02.txt
> >>> has a publication request sitting on the WG chair's desktop.
> >>>
> >>> I believe learning a LbyR is a good thing to have via DHCP, so
either
> >>> you don't like this idea, or this was a less than great example of
> >> your
> >>> point.
> >>>
> >>> If you were trying to basically say
> >>>
> >>> All LCPs don't need to have ever itty-bitty feature added
> >>> to them when another LCP proposes to add a feature.
> >>>
> >>> Then I get your point, and agree with it.
> >>>
> >>> I think the case needs to be made by the proposers of the LCP
adding
> >>> the new feature why this new feature is so important that it
should
> >>> be in every LCP.
> >>>
> >>> In other words, I don't want to have to chase every itty-bitty new
> >>> feature, but for more substantive one - there ought to be a
> >>> discussion (mandated perhaps) as to whether each LCP should have
that
> >>> feature added to all the others. This is not suggesting
necessarily
> >>> that one author or one doc needs to describe how to put this new,
> >>> more substantive feature into each remaining LCP (although, that's
an
> >>> interesting idea - that puts the burden on the original author to
> >>> port any feature into each LCP from the start).
> >>>
> >>>
> >>>> I'm not specifically arguing for or against any proposal yet; I
am
> >>>> trying to focus on the big picture; should all LCPs be roughly
> >> equally
> >>>> capable, or should some be much more restrictive, with the
admonition
> >> to
> >>>> use HELD when the situation is complex?
> >>>>
> >>>> Brian
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: James M. Polk [mailto:jmpolk@cisco.com]
> >>>>> Sent: Monday, July 14, 2008 1:38 PM
> >>>>> To: Rosen, Brian; geopriv@ietf.org
> >>>>> Subject: Re: [Geopriv] What to do about DHCP and the ever
changing
> >>>> PIDF as
> >>>>> well as HELD features
> >>>>>
> >>>>> At 09:14 AM 7/14/2008, Rosen, Brian wrote:
> >>>>>> We could do similar things with the "features" we're adding to
> >> HELD,
> >>>> or
> >>>>>> we could say "no DHCP is for a simple case of LCP and if you
need
> >>>> those
> >>>>>> features, use HELD".
> >>>>>
> >>>>> I'm not parsing this line from your message. Can you say it
> >> another
> >>>>> way, please?
> >>>>>
> >>
> >> _______________________________________________
> >> Geopriv mailing list
> >> Geopriv@ietf.org
> >> https://www.ietf.org/mailman/listinfo/geopriv
> >
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv@ietf.org
> > https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Received on Tue, 15 Jul 2008 11:14:04 -0400

This archive was generated by hypermail 2.1.8 : Tue Jul 15 2008 - 11:19:45 EDT