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

From: Stark, Barbara ^lt;bs7652@att.com>
Date: Tue Jul 15 2008 - 18:38:07 EDT

In my opinion, putting the URI capability in DHCP allows for a lot of
future changes to be indirectly supported. That is, the PIDF-LO can be
extended, and other stuff (signing, etc.) supported, without further
options or modification of options in DHCP.

I think we ought to proceed with the URI in DHCP. Other proposals to
synch DHCP with future capabilities can be proposed and scrutinized with
the knowledge that it doesn't have to do all the same things. But let's
do this one. Okay?

I don't think we need to include it in phonebcp at this time, so it's
not holding anything up. It's pretty easy, so it won't be lots of
effort.
Barbara

-----Original Message-----
From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
Behalf Of Brian Rosen
Sent: Tuesday, July 15, 2008 6:04 PM
To: 'James M. Polk'; Rosen, Brian; 'Hannes Tschofenig'; 'Romascanu, Dan
(Dan)'
Cc: geopriv@ietf.org; 'John Schnizlein'
Subject: Re: [Geopriv] What to do about DHCP and the ever changing
PIDFaswell as HELD features

I think all of this answer is why I raised the question in the first
place.

You can use these answers for each and every feature in any LCP.

If that's what we want to do, then we can justify every proposed feature
in
HELD to be incorporated in DHCP one way or another.

Is that what we want to do?

Brian

> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
Behalf
> Of James M. Polk
> Sent: Tuesday, July 15, 2008 5:20 PM
> To: Rosen, Brian; Hannes Tschofenig; Romascanu, Dan (Dan)
> Cc: geopriv@ietf.org; John Schnizlein
> Subject: Re: [Geopriv] What to do about DHCP and the ever changing
PIDF
> aswell as HELD features
>
> Brian
>
> in-line
>
> At 03:04 PM 7/15/2008, Rosen, Brian wrote:
> >I think this is unfair.
> >
> >The original HELD proposal had nearly all of the capability now
proposed
> >in the sum of the drafts.
>
> and it didn't go anywhere, for many many meetings it went nowhere
>
> >The work group desired to start with the basic LCP and go from
> >there, which the authors did.
>
> this was based on 2 reasons:
>
> #1 - DT submitted a PDF with the business decision that it was not
> going to let anyone know their location without the ability to charge
> for it, and then only give that information out for their own
> subscribers, to be inserted by some server, and not the endpoint.
>
> #2 - because Barbara Stark had the charter to persuade the WG that
> BellSouth wouldn't be upgrading any of their DSL equipment and yet
> still wanted the capability of this new information.
>
> What hasn't been talked about is that the DSL Forum, now called the
> Broadband Forum adopted DHCP as the protocol of choice in their specs.
>
> >They are now
> >bringing back individual features from the original concept, and the
> >work group is considering each feature. Nothing wrong with that.
> >
> >I think it's questionable if DHCP should be giving out an LbyR. If a
> >LIS is getting into the LbyR business, perhaps it ought to be
thinking
> >about HELD.
>
> what if a customer runs DHCP now and doesn't want to run another
protocol?
>
> DHCP has been around for quite a while now. Why shouldn't it be
> allowed to be extended to provide a URI?
>
> Why should vendors and customers require a new protocol just to get a
URI?
>
> Isn't it simpler just to extend an existing protocol, than to create
> and force the implementation and knowledge of a new one? To me, the
> latter sounds crazy.
>
> >My question is: what would DHCP LbyR get you that HELD LbyR would
not?
>
> a simpler implementation for one. Fewer protocols to configure for
> another. How about less to manage, for a third.
>
> >Why would an implementer choose DHCP when LbyR was used?
>
> I don't know - because they probably already run DHCP?
>
> Question for you: Why are you wanting to mandate a new protocol on an
> implementer just to carry a locationURI, when DHCP can so easily do
> this if extended?
>
>
> >I think we have a reasonable answer for when DHCP is a reasonable LCP
> >when civic is given. I think the argument is slightly less strong,
but
> >at least reasonable when geos are given. I'm having trouble with
DHCP
> >and lbyr.
> >
> >Why?
>
> does your laptop run HELD today?
>
> It runs DHCP already. A simple service pack (if you run windows -
> which 95% of the planet runs also) could add this Option.
>
> The same issues exist for a DHCP server on the backend when getting a
> wired Ethernet jack or AP its location. There will be some
> communication as to which jack is being asked for, and which location
> record is associated with port or AP, for example.
>
> Couple the capability of a layer 2.5 delivery protocol with that of a
> layer 2 discovery/determination method (802.11 triangulation - which
> has existed for some time now), and all that's necessary is for the
> Location Server of the Access network to populate the location
> records with the changing location of the target, identified by the
> locationURI that's given to the DHCP client by its DHCP server - and
> the client (which is a target (and maybe an LG), and what more is
needed?
>
> DHCP is a data dump delivery system. HELD is more complex.
>
>
>
> > > -----Original Message-----
> > > From: James M. Polk [mailto:jmpolk@cisco.com]
> > > Sent: Tuesday, July 15, 2008 3:42 PM
> > > To: Hannes Tschofenig; Romascanu, Dan (Dan)
> > > Cc: geopriv@ietf.org; Rosen, Brian; John Schnizlein
> > > Subject: Re: [Geopriv] What to do about DHCP and the ever changing
> >PIDF
> > > aswell as HELD features
> > >
> > > Perhaps all this excitement about whether or not DHCP gets into an
> > > arms race with HELD needs to be looked at from the opposite point
of
> > > view, which is one no one has mentioned to date. Perhaps the
> > > argument that DHCP remains very simple (supply geo, civic and lbyr
> > > and that's it) should be the model for all LCPs, one HELD should
be
> > > limited to as well. Which LCP is creating the arms race?
> > >
> > > An observation that can be seen by a blind man is that HELD is
taking
> > > on an awful lot of capabilities and features and mechanisms and no
> > > one defines HELD the same way, because there are so many optional
> > > capabilities being proposed vs accepted into the WG.
> > >
> > > DHCP should never be used to obtain GPS assistance data; but to
> > > obtain a single, simple locationURI -- I'm amazed that's getting
any
> > > resistance, even as a passing comment.
> > >
> > > At 12:05 PM 7/15/2008, Hannes Tschofenig wrote:
> > > >John,
> > > >
> > > >my pointer to deployment relates to Brian's mail entitled as:
"What
> > > >to do about DHCP and the ever changing PIDF aswell as HELD
features"
> > > >
> > > >There are problably a few additional features for DHCP to arrive
but
> > > >I have some doubts that there are too many of them.
> > > >For example, I doubt that it makes sense to obtain GPS assistance
> > > >data via DHCP.
> > > >
> > > >On the additional issue you raised: I know that the format is
also
> > > >used by LLDP-MED but the IEEE in the future with their work on
the
> > > >LLDP-MED revision will need to make an assessment what feature to
> > > >add. Additionally, I don't know about the deployment of LLDP-MED
> > > >location mechanisms either. Maybe you know more.
> > > >
> > > >Ciao
> > > >Hannes
> > > >
> > > >Romascanu, Dan (Dan) wrote:
> > > >>Yes, with the observation that LLDP-MED is not an IEEE 802.1
> >standard,
> > > >>but rather a TIA 41.4 standard, also known as ANSI-TIA 1057.
> > > >>
> > > >>Dan
> > > >>
> > > >>
> > > >>
> > > >>>-----Original Message-----
> > > >>>From: geopriv-bounces@ietf.org
[mailto:geopriv-bounces@ietf.org]
> > > >>>On Behalf Of John Schnizlein
> > > >>>Sent: Tuesday, July 15, 2008 6:59 PM
> > > >>>To: Hannes Tschofenig
> > > >>>Cc: geopriv@ietf.org; Rosen, Brian
> > > >>>Subject: Re: [Geopriv] What to do about DHCP and the ever
changing
> > > >>>PIDF aswell as HELD features
> > > >>>
> > > >>>Hannes,
> > > >>>
> > > >>>Do you really not know that the IEEE 802.1 Committee has
adopted
> > > >>>the format from RFC 3825 in their definition of LLDP-MED?
> > > >>>
> > > >>>The broad fact that many specifications of the IETF are never
> > > >>>deployed seems a poor reason to question the utility of the
DHCP
> > > >>>options for location configuration information.
> > > >>>
> > > >>>John
> > > >>>
> > > >>>On 2008Jul15, at 11:38 AM, Hannes Tschofenig wrote:
> > > >>>
> > > >>>
> > > >>>>Maybe we could ask these guys whether they are already
> > > >>>happy with the
> > > >>>>functionality being available since years or what other
> > > >>>functionality
> > > >>>>they need.
> > > >>>>
> > > >>>>I would like to avoid ending up like some other IETF groups
where
> > > >>>>researchers come up with ideas on what customers could
> > > >>>eventually find
> > > >>>>useful and then there is the big surprise many, many years
> > > >>>later that
> > > >>>>they actually want something different.
> > > >>>>
> > > >>>>Ciao
> > > >>>>Hannes
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>Rosen, Brian wrote:
> > > >>>>
> > > >>>>>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
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> > > >>>>>>...
> > > >>>>>>
> > > >>>>>>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.
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>_______________________________________________
> > > >>>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

_______________________________________________
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 18:38:07 -0400

This archive was generated by hypermail 2.1.8 : Tue Jul 15 2008 - 18:38:28 EDT