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

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 14 Jul 2008 10:14:11 -0400

If you hadn't noticed before, there is a problem created by the fact
that the DHCP extensions for an LCP aren't exactly what goes in a PIDF.
Every time we change the PIDF, we need to change the DHCP options to
match.  

We further have the problem that we have two other LCPs (HELD and
LLDP-MED) and they have different feature sets.

I'd like to start a big picture discussion of where we want to go with
this, uh, mess.

We can, of course, just continue as we have, doing DHCP updates
periodically when someone wants something new.

Another thing we could do is define an algorithm that defines the object
returned from DHCP which is automatically defined from the PIDF XML.
This means we don't change the DHCP independently of the PIDF change; a
change to PIDF automatically gives an update to the DHCP option.

Another thing we could do is to stop modifying the current options and
return either a PIDF (if it's small enough) or a URI to a PIDF if its
not.  This is not exactly the same as DHCP returning a dereferenceable
URI for LbyR.  It's simply a way for the endpoint to get a large object
from the DHCP server via HTTP.   There may be a more attractive way to
get a large object from DHCP.

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'd like to have a discussion on what we want to do, and then we can
figure out how to do it.

Brian
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 14 Jul 2008 12:37:47 -0500

>we could say "no DHCP is for a simple case of LCP and if you need those

I'm not parsing this line from your message. Can you say it another 
way, please?

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 14 Jul 2008 13:58:37 -0400

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.
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 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:[email-masked]]
> Sent: Monday, July 14, 2008 1:38 PM
> To: Rosen, Brian; [email-masked]
> Subject: Re: [Geopriv] What to do about DHCP and the ever changing
PIDF as
> well as HELD features

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 14 Jul 2008 14:00:02 -0500

>because there is some feature in HELD, we SHOULD NOT implement that

I'm with you here

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

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 14 Jul 2008 16:15:54 -0400

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

> Sent: Monday, July 14, 2008 3:00 PM
> Subject: RE: [Geopriv] What to do about DHCP and the ever changing
PIDF as
> you don't like this idea, or this was a less than great example of
your
> point.
> > > >We could do similar things with the "features" we're adding to
HELD,
> >or

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 14 Jul 2008 16:37:41 -0400

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:

>>> If we decided this was a good idea, we might not, for example,  
>>> decide
> to
>>> capable, or should some be much more restrictive, with the  
>>> admonition
> to

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 14 Jul 2008 16:41:41 -0500

The LCPs are not equal in the first place, the fact that some may work better than other in some environments already shows that. I don't see a need for all LCPs to have exactly the same feature set. If you have a NEED for a feature from one in a different LCP then we have a process for that.

Cheers
James

-----Original Message-----
From: [email-masked] on behalf of James M. Polk
Sent: Mon 7/14/2008 2:00 PM
To: Rosen, Brian; [email-masked]
Subject: Re: [Geopriv] What to do about DHCP and the ever changing PIDF as well as HELD features

I'm with you here

I'm not with you here

give that

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 14 Jul 2008 17:59:15 -0400

My experience with this kind of thing is that either you make yourself a
reasonable guideline, and stick to it, or you have a defacto arms race,
with no constraints.  There really isn't anything much in between.  What
we have now is an arms race.  Since there is no guideline, anyone is
free to suggest we put any feature in any of our LCP protocols.  So,
they do: arms race.

I don't think we ought to do that.  I think we ought to keep DHCP really
simple.   I want it to be the close to zero options, smallest footprint,
simplest deployment for both the client and the server.  I think we're
moving away from that, making it HELD with another transport.

I want the bar for a DHCP option to be very high, although I do worry
about the process for mapping a DHCP return to a PIDF.  I think we
really ought to think hard about DHCP lbyr and ask: why would you want
it when you could implement HELD?  Is there any advantage to DHCP lbyr
that HELD doesn't provide?  Is the utility of a DHCP lbyr so compelling
that every server and every client should implement it (even though that
it isn't really necessary if it's a separate option)?  There could be
such a reason.  If there is, it's a good option.  If there isn't a
compelling reason, then I think we just say no.

If I'm the only one who wants to have a simple LCP and a complex LCP,
server choice, then fine, I'll shut up.  What we have now is features
with multiple transports.  I don't think we need that.

Brian

> From: Winterbottom, James [mailto:[email-masked]]
> Sent: Monday, July 14, 2008 5:42 PM
> To: James M. Polk; Rosen, Brian; [email-masked]
PIDF as
> well as HELD features
> 
> 
> The LCPs are not equal in the first place, the fact that some may work
> better than other in some environments already shows that. I don't see
a
> need for all LCPs to have exactly the same feature set. If you have a
NEED
> for a feature from one in a different LCP then we have a process for
that.
PIDF as
your
HELD,
> > > I'm not parsing this line from your message. Can you say it
another
------------------------------------------------------------------------
--
> ----------------------
------------------------------------------------------------------------
--
> ----------------------

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 14 Jul 2008 17:56:10 -0500

I can see your point. However, I believe that, on the whole, the WG is capable of coming to sensible conclusions on individual submissions.

It helps to have the topic aired - and some basic guidelines discussed.  I think that Henning's general view is a good basis for analysing submissions.  It really comes down to whether the proposal is suited to the particular LCP.  For instance, there has been discussion on additions to DHCP that I don't see as important, namely: uncertainty and confidence, digital signatures.  Based on the current state of understanding on these topics, the cost of adding these to DHCP (in protocol complexity, payload size) far outweighs any potential benefits.

In all honesty, I don't see that it's worth discussing at length, until such time as a crank submission is made.  I'm not seeing any in the current batch.  I can see your point on the DHCP LbyR, but at least it's cost is relatively small.

Cheers,
Martin

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Rosen, Brian
> Sent: Tuesday, 15 July 2008 7:59 AM
> To: Winterbottom, James; James M. Polk; [email-masked]
> Subject: Re: [Geopriv] What to do about DHCP and the ever changing PIDF
> aswell as HELD features
> 
> > > > >we could say "no DHCP is for a simple case of LCP and if you
> need
> > >those
> > > > >features, use HELD".
> > > >

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 15 Jul 2008 18:09:30 +0300

>> has a publication request sitting on the WG chair's desktop.
What does this mean? Is the document, in the view of the author, finished?

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 15 Jul 2008 18:10:31 +0300

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.

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 15 Jul 2008 11:14:04 -0400

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:[email-masked]]
> Sent: Tuesday, July 15, 2008 11:11 AM
> To: Henning Schulzrinne
> Cc: Rosen, Brian; [email-masked]; James M. Polk
PIDF as
> >> The document (Internet Draft) for DHCP lbyr is fine; I'm asking
what
> the
> >> What makes LbyR be worthy of inclusion, and let's say, -context
not?
> Or
decide
> >>>> retrieving an LbyR from DHCP.
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-lbyr-uri-
> >>> option-02.txt
admonition
need

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 15 Jul 2008 18:38:08 +0300

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:
>> I agree with Henning that it will be difficult to come up with a
>>     
> general
>   
>> based mechanisms given that they have been finished already some time
>>     
> ago.
>   
>>> "general applicability", "low change frequency" and "size". Items
>>>       
> only
>   
>>> In general, I think it would be good to make this decision
>>>       
> explicitly,
>   
>>> My general bias, given that all of these are optional, is to make
>>>       
> them
>   
>>>> 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
>   
>>>> guideline for accepting a work item for inclusion in DHCP-as-LCP
>>>>         
> ought
>   
>>>> to be.
>>>>
>>>>>> because there is some feature in HELD, we SHOULD NOT implement
>>>>>>             
> that
>   
>>>>>> feature in DHCP.
>>>>>>             
>>>>> I'm with you here
>>>>>
>>>>>           
>>>>>> accept several of the more recent proposals for, to give an
>>>>>>             
> example,
>   
>>>>> I believe learning a LbyR is a good thing to have via DHCP, so
>>>>>           
> either
>   
>>>>> 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.
>>>>>
>>>>> discussion (mandated perhaps) as to whether each LCP should have
>>>>>           
> that
>   
>>>>> feature added to all the others. This is not suggesting
>>>>>           
> necessarily
>   
>>>>> more substantive feature into each remaining LCP (although, that's
>>>>>           
> an
>   
>>>>>> 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
>>>>         
>>>>>>> Subject: Re: [Geopriv] What to do about DHCP and the ever
>>>>>>>               
> changing
>   
>>>>>> PIDF as
>>>>>>             
>>>>>>> well as HELD features
>>>>>>>
>>>>>>> I'm not parsing this line from your message. Can you say it
>>>>>>>               
>>>> another
>>>>         
>>>>>>> way, please?
>>>>>>>
>>>>>>>

---

From: John Schnizlein <[email-masked]>
Date: Tue, 15 Jul 2008 11:58:56 -0400

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 15 Jul 2008 18:41:59 +0200

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of John Schnizlein
> Sent: Tuesday, July 15, 2008 6:59 PM
> To: Hannes Tschofenig
> Cc: [email-masked]; Rosen, Brian
> 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
> 
> >> You will have to wait another year, or maybe more, to use 
> deployment 
> >> as a guide.
> >>
> >> Brian
> >>
> >>
> >>> 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.
> >>>
> >>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 15 Jul 2008 20:05:16 +0300

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:
>>> Maybe we could ask these guys whether they are already 
>>>       
>> happy with the 
>>     
>>> functionality being available since years or what other 
>>>       
>> functionality 
>>     
>>> they need.
>>>
>>> researchers come up with ideas on what customers could 
>>>       
>> eventually find 
>>     
>>> useful and then there is the big surprise many, many years 
>>>       
>> later that 
>>     
>>>> There is no deployment of anything yet, but I do 
>>>>         
>> understand there are 
>>     
>>>> plans for some DHCP deployment in some cable systems and 
>>>>         
>> enterprises.
>>

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 15 Jul 2008 14:41:35 -0500

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
>
>>>From: [email-masked] [mailto:[email-masked]] 
>>>On Behalf Of John Schnizlein
>>>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?
>>>
>>>deployed seems a poor reason to question the utility of the DHCP 
>>>options for location configuration information.
>>>
>>>John
>>>
>>>>>>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.
>>>>>>
>>>>>>
>>>>>>

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 15 Jul 2008 16:04:14 -0400

I think this is unfair.

The original HELD proposal had nearly all of the capability now proposed
in the sum of the drafts.  The work group desired to start with the
basic LCP and go from there, which the authors did.  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.
My question is: what would DHCP LbyR get you that HELD LbyR would not?
Why would an implementer choose DHCP when LbyR was used?

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?

> Sent: Tuesday, July 15, 2008 3:42 PM
> To: Hannes Tschofenig; Romascanu, Dan (Dan)
> Cc: [email-masked]; Rosen, Brian; John Schnizlein
PIDF

---

From: Richard Barnes <[email-masked]>
Date: Tue, 15 Jul 2008 16:32:15 -0400

> Why would an implementer choose DHCP when LbyR was used?

To give a simplistic answer, it's one fewer transaction:

DHCP:
1. Get URI

HELD:
1. Discover LIS
2. Get URI

Keep in mind that LbyR and LCP/HELD are independent functions.  A 
dereference server can lack support for HTTP, and a LIS/LCP server can 
not support LbyR.

As a concrete example, suppose I assign a presence URI to every DHCP 
client in my enterprise WiFi network, so that they and I can subscribe 
to their location as they roam.  With DHCP LbyR, I could push that URI 
out to them and never have to think about HELD or HTTP.

--Richard

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 15 Jul 2008 16:19:44 -0500

Brian

in-line

At 03:04 PM 7/15/2008, Rosen, Brian wrote:
>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

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?

>at least reasonable when geos are given.  I'm having trouble with DHCP

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.

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 15 Jul 2008 16:31:08 -0500

James,

Let us be extremely clear about the difference a HELD location URI and a DHCP location URI and in particular what the difference means when you are behind a NAT!

If you are using DHCP to acquire the URI then you cannot be behind a NAT no way any how as it means that you don not have a URI per user, you have a URI per household. The URI in DHCP does not allow the possession model, which means that the owner of the URI HAS TO provide rules to the LIS (though they have no way to find the LIS to publish the rules to is specified).

I will add now also, that when we talked about HELD there was a lot of discussion about VPNs etc, and it was pointed out that most of this was equally applicable to a DHCP location solution. There was some banter, but it was decided that we would not update the existing DHCP location specifications. However, this is a new draft, and it needs to address the VPN aspects and how to avoid these pitfalls, or not use this specification when the conditions can be detected. 

I also think that it is very unfair to single Barbara out on this, I think you will find that a sizable majority of operators were, and still are in favour of a HELD location solution in their networks over a DHCP one.

Cheers
James

-----Original Message-----
From: [email-masked] on behalf of James M. Polk
Sent: Tue 7/15/2008 4:19 PM
To: Rosen, Brian; Hannes Tschofenig; Romascanu, Dan (Dan)
Cc: [email-masked]; John Schnizlein
Subject: Re: [Geopriv] What to do about DHCP and the ever changing PIDF aswell as HELD features
 
Brian

in-line

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 15 Jul 2008 17:55:03 -0400

James P said:
 - and - 

Just so we're clear -- The Broadband Forum does indeed have specs
supporting DHCP client for IP address acquisition (plus DNS, IP gateway,
and subnet mask), and DHCP server for handing out IP addresses (plus
DNS, IP gateway, and subnet mask) to LAN devices. It currently has a
draft for emergency services requirements that references phonebcp,
which says to support DHCP, HELD, and LLDP-MED as LCPs. That document
also recommends trying LCPs from the bottom up (of the protocol stack).
That doesn't mean DHCP has been adopted as *the* protocol of choice for
location config.

I also agree that it would be easy to add the DHCP URI option and hope
that work will continue. 

Can't we just move forward, accept decisions that have been made, and
get the work done?
Barbara
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 15 Jul 2008 18:04:05 -0400

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

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of James M. Polk
> Sent: Tuesday, July 15, 2008 5:20 PM

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 15 Jul 2008 18:38:07 -0400

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: [email-masked] [mailto:[email-masked]] 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: [email-masked]; '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.

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.

Brian

> From: [email-masked] [mailto:[email-masked]] On
Behalf
PIDF
> > > >>>From: [email-masked]
[mailto:[email-masked]]
changing
> > > >>>Do you really not know that the IEEE 802.1 Committee has
adopted
> > > >>>deployed seems a poor reason to question the utility of the
DHCP

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 16 Jul 2008 01:24:31 -0500

Thank you Barbara

The DHCP LbyR ID was "publication requested" a month ago (right after 
the interim) - , so it shouldn't be lagging behind phoneBCP, it might 
even be ahead of it.

James

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 16 Jul 2008 01:30:40 -0500

Umm....

No offence, but I have just looked through my inbox for the last 6
months and cannot see a WGLC on this document.

Would you be so kind as to post the WGLC email please?

Cheers
James

Behalf
> Of James M. Polk
> Sent: Wednesday, 16 July 2008 4:25 PM
> To: Stark, Barbara; Brian Rosen; Rosen, Brian
> Cc: [email-masked]
PIDF as

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 16 Jul 2008 02:02:31 -0500

>Would you be so kind as to post the WGLC email please?

it's just the request, not the announcement of WGLC. Do you want that?

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 16 Jul 2008 02:03:43 -0500

I guess what I am asking is whether the document has completed last call
or not. I didn't think it had.

Cheers
James

> Sent: Wednesday, 16 July 2008 5:03 PM
> To: Winterbottom, James; Stark, Barbara; Brian Rosen; Rosen, Brian
> Cc: [email-masked]
PIDF as
> > > From: [email-masked] [mailto:[email-masked]]
On
>-----------------------------------------------------------------------
--
> -----------------------
>-----------------------------------------------------------------------
--
> -----------------------

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 16 Jul 2008 03:04:44 -0500

>or not. I didn't think it had.

no, Robert hasn't started WGLC yet

here is the URL, BTW

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 16 Jul 2008 11:13:04 +0300

This seems to be a good response to Brian's mail.

Brian, there isn't a problem as DHCP will not see so many extensions.

James M. Polk wrote:
> 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?
>
> on an awful lot of capabilities and features and mechanisms and no one 
> defines HELD the same way, because there are so many optional 
> DHCP should never be used to obtain GPS assistance data; but to obtain 
> a single, simple locationURI  -- I'm amazed that's getting any 
>>>> Behalf Of John Schnizlein

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 16 Jul 2008 11:17:24 +0300

None of my review comments made it into the document.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 16 Jul 2008 11:20:15 +0300

> it's just the request, not the announcement of WGLC. Do you want that?
Given that my comments have not been addressed at all (and most of them 
related to security) I personally believe that this document is anywhere 
near a WGLC.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 16 Jul 2008 11:35:05 +0300

> Is that what we want to do?

I think the answer is that we need to decide these type of things on a 
case-by-case basis.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 16 Jul 2008 11:41:51 +0300

We know everyone's opinion on this subject already.

The working group has already made clear decisions on this and it is not 
particularly useful to rehash them again.

James M. Polk wrote:
>> The work group desired to start with the basic LCP and go from there, 
>> which the authors did.
>
> Location Server of the Access network to populate the location records 
> with the changing location of the target, identified by the

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 16 Jul 2008 04:00:39 -0500

At 03:20 AM 7/16/2008, Hannes Tschofenig wrote:
>Given that my comments have not been addressed at all (and most of 
>them related to security) I personally believe that this document is 
>anywhere near a WGLC.

we discussed this document at the interim, which you attended, and 
you said nothing at the interim regarding this document.

no reminder that I had forgotten anything. no pointer to your post 
that I should refer to (your comments)...

interesting

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 16 Jul 2008 04:14:56 -0500

At 04:00 AM 7/16/2008, James M. Polk wrote:
>>them related to security) I personally believe that this document 
>>is anywhere near a WGLC.
>

ah, I found your comments.

I'll respond to that message (again, cuz I already had responded to 
it once before)

---

From: Marc Linsner <[email-masked]>
Date: Wed, 16 Jul 2008 08:48:32 -0400

James W.,

I'm confused about your assertions on how DHCP works behind/through a NAT.
The DHCP protocol itself is agnostic to NATs in the same way it is to layer
3 routers.  DHCP is broadcast based, meaning the discover packet does not
transverse a layer 3 (NAT or router) element without the aid of a dhcp relay
agent. There is nothing to prevent a dhcp relay agent from being co-located
with a NAT, but this deployment model would seem odd as NATs are typically
utilized to 'hide' the inside network from the outside network.  Typical
deployment is for a DHCP server to reside on the inside network.  If, in
fact, a deployment utilized a DHCP server on the outside network for
configuration of hosts on the inside network (DHCP traffic crossing a NAT
device), the DHCP server could receive the same option 82 and giaddr
attributes which are used to uniquely identify the host/network on the
inside.  Of course this requires dhcp relay agent(s) on the inside network,
the same as when a layer 3 router is between the host and DHCP server.

Hence, from a protocol perspective, NATs don't add any more complexity to
the LCP DHCP model than routers.  It's a simple case that NATs typically are
deployed at admin boundaries such that DHCP servers used for host
configuration on the inside network reside on the inside network.

I also don't understand how a location URI delivered to a host via DHCP has
any bearing on whether the URI is treated as 'possession model' or
'authorization model' when dereferenced at the LIS.

-Marc-

On 7/15/08 5:31 PM, "Winterbottom, James" <[email-masked]>
wrote:

> James,
> 
> Let us be extremely clear about the difference a HELD location URI and a DHCP
> location URI and in particular what the difference means when you are behind a
> NAT!
> 
> If you are using DHCP to acquire the URI then you cannot be behind a NAT no
> way any how as it means that you don not have a URI per user, you have a URI
> per household. The URI in DHCP does not allow the possession model, which
> means that the owner of the URI HAS TO provide rules to the LIS (though they
> have no way to find the LIS to publish the rules to is specified).
> 
> I will add now also, that when we talked about HELD there was a lot of
> discussion about VPNs etc, and it was pointed out that most of this was
> equally applicable to a DHCP location solution. There was some banter, but it
> was decided that we would not update the existing DHCP location
> specifications. However, this is a new draft, and it needs to address the VPN
> aspects and how to avoid these pitfalls, or not use this specification when
> the conditions can be detected.
> 
> I also think that it is very unfair to single Barbara out on this, I think you
> will find that a sizable majority of operators were, and still are in favour
> of a HELD location solution in their networks over a DHCP one.
> 
> Cheers
> James
> 
> 
> 
>

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 16 Jul 2008 10:51:43 -0400

Okay, I would like to propose that the context feature proposed for HELD be
extended to work for DHCP.

>DHCP has been around for quite a while now.  Why shouldn't it be allowed to
be extended to provide context for the URI?

>Why should vendors and customers require a new protocol just to get context
for the URI?

>Isn't it simpler just to extend an existing protocol, than to create and
force the implementation and knowledge of a new one?  

>Why are we wanting to mandate a new protocol on an implementer just to
carry context for a locationURI, when DHCP can so easily do this if
extended?

>It runs DHCP already.  A simple service pack (if you run windows - which
95% of the planet runs also) could add this Option.

> Sent: Wednesday, July 16, 2008 4:35 AM
> To: Brian Rosen
> Cc: 'James M. Polk'; Rosen, Brian; 'Romascanu, Dan (Dan)';
> [email-masked]; 'John Schnizlein'

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 16 Jul 2008 10:16:47 -0500

>My arguments for this feature are the same as James presented for LbyR URIs:

interesting tactic to justify why you want to write a draft... why 
didn't you just write it, then talk about it?

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 16 Jul 2008 19:40:19 +0300

> didn't you just write it, then talk about it?

Write something, Brian.

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 16 Jul 2008 18:54:38 -0500

Hi Marc,

You comments below actually highlight several things.
Firstly that the DHCP location URI solution isn't a total solution, it
is a fragment that does not include the larger picture, and secondly I
suspect that you don't really see what the larger picture is.

In order for a reference to be useful, it needs to reference something.
More importantly, when something asks for a reference, that reference
should only be applicable to the thing actually asking for it.
Consequently regardless of whether two people are in the same house,
with an internal network, behind a NAT that is connected to the same
ISP, I expect each host to ask for, and be given independent URIs. I can
do this with HELD, I don't see how I can do this with DHCP unless I
modify the home-router somehow.

This is a real deployment use case, and it requires a real deployment
solution.

The second case is the VPN use-case, that I believe you largely bring up
time and time again. My modem establishes, unbeknownst to me, a VPN to
my enterprise in Chicago. I connect my host inside my home network, and
it does all its DHCP stuff, the DHCP server I cam talking to is in
Chicago, so any location Uri request will go to their. The DHCP solution
being described is just as vulnerable to this setup as any application
layer protocol. Since we were forced to discuss these issues in the HELD
draft so to must they be discussed in the DHCP draft.

I believe that the realm of applicability for a DHCP location URI is
very restrictive, and I would like to see some of those restrictions
included in the draft before we move it to a last call.

Cheers
James

> From: Marc Linsner [mailto:[email-masked]]
> Sent: Wednesday, 16 July 2008 10:49 PM
> To: Winterbottom, James
> Cc: [email-masked]
PIDF
> the LCP DHCP model than routers.  It's a simple case that NATs
typically
> are
> I also don't understand how a location URI delivered to a host via
DHCP
> has
> > Let us be extremely clear about the difference a HELD location URI
and a
> DHCP
> > location URI and in particular what the difference means when you
are
> behind a
> > NAT!
> >
> > If you are using DHCP to acquire the URI then you cannot be behind a
NAT
> no
> > way any how as it means that you don not have a URI per user, you
have a
> URI
> > means that the owner of the URI HAS TO provide rules to the LIS
(though
> they
> > equally applicable to a DHCP location solution. There was some
banter,
> but it
> > specifications. However, this is a new draft, and it needs to
address
> the VPN
> > aspects and how to avoid these pitfalls, or not use this
specification
> when
> > will find that a sizable majority of operators were, and still are
in
> favour
PIDF
> aswell
> > as HELD features
> > Why should vendors and customers require a new protocol just to get
a
> URI?
changing
adopted
DHCP
> ------
> > ------------------
> ------
> > ------------------

---

From: Ted Hardie <[email-masked]>
Date: Wed, 16 Jul 2008 17:05:29 -0700

>should only be applicable to the thing actually asking for it.

Could you possibly rephrase the statement above?  As written,
it appears to pretty much contradict how URIs as a whole are
meant to work, and it makes it really hard to understand the
rest of your argument below.

>modify the home-router somehow.

The requirement driving this is opaque to me.  If a protocol
chooses to use the same URI for all references to the same
location (mumblefratz://authority.example/civiclocation1),
what is the issue?

You could, of course, choose to obfuscate this (mumblefratz://authority.example/
?hash_of_MAC_address_and_civiclocation1) so that you had independent
URIs for each requestor, but the reason you don't want the first
version is not at all clear to me.

Thanks for any enlightenment,
				Ted

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 16 Jul 2008 19:08:43 -0500

Hi Ted,

The reason is that to my mind I have policies (possession or otherwise)
that get invoked when a location URI is dereferenced. If you and I have
the same URI and we each give it to different entities, how the LIS
supposed to know which policies to invoke?

Cheers
James

> From: Ted Hardie [mailto:[email-masked]]
> Sent: Thursday, 17 July 2008 10:05 AM
> To: Winterbottom, James; Marc Linsner
> Cc: [email-masked]
PIDF

---

From: Ted Hardie <[email-masked]>
Date: Wed, 16 Jul 2008 21:21:05 -0700

>supposed to know which policies to invoke?

But these policies are unrelated to the location retrieved, yes? 

If  there is a single policy for retrieval by all requestors at location
X, retrieval can be invoked using the same URI.  If, as a side-effect of the
retrieval, you want to have some other processing take place
which requires you to know which requestor at location X
made the request, then you can disambiguate them in the
URI using any number of ways (using a query part that
hashes together the MAC address and the PIDF-LO was
what that second mumblefratz: example gave for that and
there are no doubt much cleverer ways). 

But this seems like something that is worked out entirely
during the deployment, not something that the protocol
itself needs to worry about.  As long as the URI schemes
chosen fall into the usual list (that is, aren't "data"
or "opaquelocktoken" or friends),  using query parts,
paths, user parts, or other aspects to disambiguate them
is relatively easy.  It's also easy to *avoid* them when
the deployment doesn't need them and can provide
a constant URI  to something like the civic location of the
house in which the network sits.

Driving all deployments to use unique URIs on a per-machine
basis does not seem to me needed, and the criticism of
the DHCP protocol mechanism on this basis isn't apt anyway.
Including a URI allows you to use unique URIs where the
deployment requires them; it simply isn't a protocol level
requirement.

At least, that's how it seems to me.

			regards,	
				Ted Hardie

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 16 Jul 2008 23:29:12 -0500

Hi Ted,

Just so I am clear then, do you see the following two URIs as being the
same?

https://lis.examples.com:9127/dxjediodkjcndjkcvnjkdnjkd
and
https://lis.examples.com:9127/3278x893ujz0o4ekdi4eikxd

To be clear from my side, absolutely these policies related to the
location that is ultimately revealed. Indeed if I follow the guidelines
laid out in the LbyR requirements document, using the approach you
describe and the example I used before, I could void your location URI
since it is shared.

So I see this as very pertinent to the discussion.

Cheers
James

> Sent: Thursday, 17 July 2008 2:21 PM
PIDF
> X, retrieval can be invoked using the same URI.  If, as a side-effect
of
> >> >ISP, I expect each host to ask for, and be given independent URIs.
I
> >can
--
--

---

From: "Hardie, Ted" <[email-masked]>
Date: Wed, 16 Jul 2008 23:06:37 -0700

>https://lis.examples.com:9127/3278x893ujz0o4ekdi4eikxd

RFC 3986/STD 66, section 6.2 has a whole lot of text
on the "ladder of comparison".  Which type of comparison
are you discussing?  For almost all of them, the answer
will be no, but that doesn't seem to really go to point you raised in
your original mail:

"More importantly, when something asks for a reference, that
reference should only be applicable to the thing actually asking for it."

Whether those two URIs *refer to the same location* is
unrelated to the question of whether they string match
and it is equally unrelated to the question of whether they would be
handed to different requestors.

You appear to me to be asking for a  property (each requestor
gets a unique URI)  which doesn't actually relate to whether the
requestor is at that location.  You also appear to be relating one
of the above properties to some flaw you see in DHCP carrying URIs,
but remains really hard to work out where you see the
problem.  It is entirely possible with any protocol slot
capable of carrying URIs to do exactly what you want.
It may be recommended for some deployments; it may not
be necessary for others, and those might use URIs which did
not carry uniqueness properties.

It's late here, so I'll likely follow up further replies tomorrow,

regards,

Ted

---

From: Marc Linsner <[email-masked]>
Date: Thu, 17 Jul 2008 08:56:54 -0400

James,

First, I understand the big picture, but my understanding is not anchored in
a product solution.

Second, you made assertions about DHCP that are false.  I am correcting
those assertions.

Fact: The DHCP protocol set has the ability to uniquely identify all hosts
requesting configuration options (yes, civic, geo, and uri options) without
regard to the location of the DHCP server.

If you, James W., stop and think for a minute, if this weren't true, how
would a DHCP server assign a unique and correct IP address to each host?

In addition, DHCP delivers the level of privacy and security on all
requests/offers that is agreed to by the working group to meet the guiding
principles.

-Marc-

On 7/16/08 7:54 PM, "Winterbottom, James" <[email-masked]>
wrote:

>> I'm confused about your assertions on how DHCP works behind/through a
> 
> NAT.
> 
>> The DHCP protocol itself is agnostic to NATs in the same way it is to
> 
>> layer
> 
>> 3 routers.  DHCP is broadcast based, meaning the discover packet does
> 
> not
> 
>> transverse a layer 3 (NAT or router) element without the aid of a dhcp
> 
>> relay
> 
>> agent. There is nothing to prevent a dhcp relay agent from being co-
> 
>> located
> 
>> with a NAT, but this deployment model would seem odd as NATs are
> 
> typically
> 
>> utilized to 'hide' the inside network from the outside network.
> 
> Typical
> 
>> deployment is for a DHCP server to reside on the inside network.  If,
> 
> in
> 
>> configuration of hosts on the inside network (DHCP traffic crossing a
> 
> NAT
> 
>> inside.  Of course this requires dhcp relay agent(s) on the inside
> 
> network,
> 
>> Hence, from a protocol perspective, NATs don't add any more complexity
> 
> to
> 
>> On 7/15/08 5:31 PM, "Winterbottom, James"
> 
> <[email-masked]>
> 
>> wrote:
> 
>> 
> 
>>> James,
> 
>>> 
> 
>>> per household. The URI in DHCP does not allow the possession model,
> 
>> which
> 
>>> I will add now also, that when we talked about HELD there was a lot
> 
> of
> 
>>> discussion about VPNs etc, and it was pointed out that most of this
> 
> was
> 
>>> I also think that it is very unfair to single Barbara out on this, I
> 
>> think you
> 
>>>> The original HELD proposal had nearly all of the capability now
> 
>> proposed
> 
>>> going to let anyone know their location without the ability to
> 
> charge
> 
>>> 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
> 
>>>> 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?
> 
>>> 
> 
>>>> My question is: what would DHCP LbyR get you that HELD LbyR would
> 
> not?
> 
>>> 
> 
>>> Question for you: Why are you wanting to mandate a new protocol on
> 
> an
> 
>>>> 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?
> 
>>> 
> 
>>> The same issues exist for a DHCP server on the backend when getting
> 
> a
> 
>>> communication as to which jack is being asked for, and which
> 
> location
> 
>>> Couple the capability of a layer 2.5 delivery protocol with that of
> 
> a
> 
>>> the client (which is a target (and maybe an LG), and what more is
> 
>> needed?
> 
>>> 
> 
>>>>> arms race with HELD needs to be looked at from the opposite point
> 
> of
> 
>>>>> and that's it) should be the model for all LCPs, one HELD should
> 
> be
> 
>>>>> An observation that can be seen by a blind man is that HELD is
> 
> taking
> 
>>>>> obtain a single, simple locationURI  -- I'm amazed that's getting
> 
> any
> 
>>>>>> 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
> 
>>>>>> 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
> 
>>>>>>> Yes, with the observation that LLDP-MED is not an IEEE 802.1
> 
>>>> standard,
> 
>>>>>>>>> I would like to avoid ending up like some other IETF groups
> 
> where
> 
>>>>>>>>>>> some stuff isn't deployed? To some extend that relates to
> 
> the
> 
>>>>>>>> discussion
> 
>>>>>>>>>>> around fixing DHCP-geo.
> 
>>>>>>>>>>> 
> 
>>>>>>>>>>> 
> 
>>>>>>>>>>> 
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 17 Jul 2008 16:19:20 -0500

Marc,

So your ISP knows about ever single host inside your NAT at home does it?
I am most surprised.

Cheers
James

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]]
Sent: Thu 7/17/2008 7:56 AM
To: Winterbottom, James
Cc: [email-masked]
Subject: Re: [Geopriv] What to do about DHCP and the ever changing PIDF aswell as HELD features
 
James,

-Marc-

---

From: Marc Linsner <[email-masked]>
Date: Thu, 17 Jul 2008 17:31:03 -0400

James,

You obviously have a deployment model in your mind that you are not sharing.
It would be helpful if you articled such when you make statements about what
a particular protocol will/won't support.  Please explain what you are
trying to accomplish.

-Marc-

>>>>>>>>>>>> some stuff isn't deployed? To some extend that relates to
----------------------------------------------------------------------------->>
-
----------------------------------------------------------------------------->>
-

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 17 Jul 2008 18:06:59 -0500

Hi Marc,

The use case and deployment scenario is articulated below.

Cheers
James

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]]
Sent: Thu 7/17/2008 4:31 PM
To: Winterbottom, James
Cc: [email-masked]
Subject: Re: [Geopriv] What to do about DHCP and the ever changing PIDF aswell as HELD features
 
James,

-Marc-

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 21 Jul 2008 18:27:29 -0500

I'm going to jump back to this part of the thread for a moment

At 06:54 PM 7/16/2008, Winterbottom, James wrote:
>Firstly that the DHCP location URI solution isn't a total solution

What is a a total solution in DHCP?

If DHCP is not a total solution - why does it exist?

>, it
>is a fragment that does not include the larger picture,

that's by design (not mine BTW)

>and secondly I suspect that you don't really see what the larger picture is.

oh, again with that personal attacks

>In order for a reference to be useful, it needs to reference something.

no, something needs to be at the reference. There's a difference.

>should only be applicable to the thing actually asking for it.

I think you have this completely backwards.

Let me explain:

If my family is in my house, then it doesn't matter who asks any of 
my family members where they are, they are in my house.  It doesn't 
matter if it is a friend of my wife's, or a policeman.  You state 
clearly above that it does matter, and I'm like you to explain how it 
does.  The answer is it doesn't, unless you get into permissions and 
authentication of the asker - which is a completely different topic 
that what's at the reference.

>ISP, I expect each host to ask for, and be given independent URIs.

why?

It doesn't matter - the information at the reference - is the same.

The only time it matters is if the "network" doesn't track one of the 
two people, and they have moved.  This isn't a burden on the protocol 
used, if the protocol doesn't let communication continue outside of the house.

In other words, once anyone's device leaves my house's internal 
network, that DHCP information -- all of it -- is no longer good, 
which means none of it can be used to communicate with any other 
device on the Internet.  The burden is on the endpoint to ask for and 
receive new DHCP information (with or without options 99 or 123) in 
order to have the ability to communicate.

An IP address received in my house will not route on the Internet, 
therefore there is no communication.

>I can
>do this with HELD,

bravo

that doesn't mean all LCP's have to do this

>I don't see how I can do this with DHCP unless I

you can't, but that isn't a function of the "home-router", it's a 
function of moving outside the realm of that DHCP server.

>This is a real deployment use case, and it requires a real deployment

well, I believe we are talking past each other at the networking 
layer, which is necessary for ALL IP communications

>Chicago, so any location Uri request will go to their.

where have you been?

We've been talking about DHCP Options being limited to the local LAN 
only, and not to have the endpoint override what's learned within the 
VPN for years now.  How you missed this whole area of discussion?

>The DHCP solution
>layer protocol.

not necessarily

If the timing of the application layer location determination occurs 
after the VPN is brought up, then it doesn't work.

The limitation of the DHCP solution is that everything needs to be 
learned before the VPN is active, and not to have the endpoint 
overwrite anything learned within the VPN.

>Since we were forced to discuss these issues in the HELD

I'll cover this topic when I modify the doc to incorporate what I 
accept from Hannes's message about the ID.

>included in the draft before we move it to a last call.

see above