Subject: [dhcwg] review of draft-ietf-geopriv-dhcp-lbyr-uri-option

From: Ralph Droms <[email-masked]>
Date: Mon, 3 Oct 2011 16:05:44 -0400

I'd appreciate a review of draft-ietf-geopriv-dhcp-lbyr-uri-option.  Are there any issues, especially with the option format, the suggestions about dealing with large URIs or the inclusion of a separate lifetime in the Location URI?

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Oct 2011 20:22:34 +0000

On Oct 3, 2011, at 4:05 PM, Ralph Droms wrote:
I'd appreciate a review of draft-ietf-geopriv-dhcp-lbyr-uri-option.  Are there any issues, especially with the option format, the suggestions about dealing with large URIs or the inclusion of a separate lifetime in the Location URI?

Having a separate lifetime is certainly an issue!   :)

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 03 Oct 2011 17:03:40 -0500

At 03:22 PM 10/3/2011, Ted Lemon wrote:
>Content-Language: en-US
>Content-Type: multipart/alternative;
>         boundary="_000_2207D364CADB43D2907B204180A6E4CCnominumcom_"
>
>>I'd appreciate a review of 
>>draft-ietf-geopriv-dhcp-lbyr-uri-option.  Are there any issues, 
>>especially with the option format, the suggestions about dealing 
>>with large URIs or the inclusion of a separate lifetime in the Location URI?
>

This wasn't my idea. This was something several members of the 
Geopriv WG wanted, and the chairs directed me to incorporate it into the draft.

Geopriv as a WG is worried about location information becoming or 
being stale (i.e., old or out of date or "no longer 
valid/applicable"). I tried to argue that what this doc does is 
create a means to download the URI pointing to the location 
information (of a client) that can change without updating the URI. 
But some believed (and still do) that if the location of the client 
changes, so must the URI.

I lost that battle.

I have no problems with having the location URI lifetime be exactly 
the same as what covers the rest of what comes from DHCP (i.e., use 
of one lease is good enough for me, but the WG needs to be convinced of this).

James

>_______________________________________________
>dhcwg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Oct 2011 23:03:20 +0000

On Oct 3, 2011, at 6:03 PM, James M. Polk wrote:
Geopriv as a WG is worried about location information becoming or being stale (i.e., old or out of date or "no longer valid/applicable"). I tried to argue that what this doc does is create a means to download the URI pointing to the location information (of a client) that can change without updating the URI. But some believed (and still do) that if the location of the client changes, so must the URI.

Wouldn't the client get a new address if its location changed?

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 04 Oct 2011 12:32:06 -0500

>Wouldn't the client get a new address if its location changed?

that argument was tried and failed too...

2 reasons were given:

#1 - some were thinking that really flat networks wouldn't 
necessarily change the router interface even when the dot11 APs changed;

#2 - cellular doesn't change an IP address even though an AP or tower 
changes (DHCP is now part of IMS for those that didn't know).

James

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Oct 2011 17:39:04 +0000

On Oct 4, 2011, at 1:32 PM, James M. Polk wrote:
#1 - some were thinking that really flat networks wouldn't necessarily change the router interface even when the dot11 APs changed;

Putting a lifetime on the configuration information doesn't solve this problem, because it's unrelated to movement between access points.   A lifetime on the IP address will accomplish the same thing, but it doesn't solve the problem you've stated here.   In order to solve this problem, you have to refresh the information when the AP changes, which is not something DHCP can do.

#2 - cellular doesn't change an IP address even though an AP or tower changes (DHCP is now part of IMS for those that didn't know).

In this situation you are not using DHCP, so it's not an issue.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 04 Oct 2011 15:06:23 -0500

At 12:39 PM 10/4/2011, Ted Lemon wrote:
>Putting a lifetime on the configuration information doesn't solve 
>this problem, because it's unrelated to movement between access 
>points.   A lifetime on the IP address will accomplish the same 
>thing, but it doesn't solve the problem you've stated here.   In 
>order to solve this problem, you have to refresh the information 
>when the AP changes, which is not something DHCP can do.

I shortened the bullet, but what you say above is part of what I 
suggested (i.e., needing a trigger upon change of an AP), but that 
didn't satisfy the discussion in Geopriv.

>>#2 - cellular doesn't change an IP address even though an AP or 
>>tower changes (DHCP is now part of IMS for those that didn't know).
>

as cut-n-dry (or black-n-white) as you see this, others see grey 
(unfortunately).

The DHC WG stating there is a problem with the Valid-For field within 
this document is something concrete that the (Geopriv) chairs would 
need to address with and into DHC, IMO.

Do others have the same issue with this draft?

James

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Oct 2011 20:25:33 +0000

On Oct 4, 2011, at 4:06 PM, James M. Polk wrote:
> I shortened the bullet, but what you say above is part of what I suggested (i.e., needing a trigger upon change of an AP), but that didn't satisfy the discussion in Geopriv.

Interesting.   So they are willing to take a solution that doesn't fix the problem, but reject a solution that does fix the problem?   They can certainly fly in the face of reason like this if they want, but that's not a good reason to change the way the DHCP protocol works.

> as cut-n-dry (or black-n-white) as you see this, others see grey (unfortunately).

This is actually the same as the previous question.   Even if they were to use DHCP, a lifetime on the address wouldn't actually solve the stated problem, because again the device needs to notice that it's changed cells.

And by the way, in both of these cases, even supposing that we did change the DHCP protocol in the way that's been proposed, how would the DHCP server know that the device was connecting through a different access point or cell tower?

> The DHC WG stating there is a problem with the Valid-For field within this document is something concrete that the (Geopriv) chairs would need to address with and into DHC, IMO.

Right, so I would be curious to hear from other DHC working group members as to whether they have an opinion on whether the DHCP protocol should be extended with an additional lifetime on geopriv URIs.   Bear in mind that all DHCP clients would have to be modified to support this feature.

Thoughts?   Comments?

---

From: Ralph Droms <[email-masked]>
Date: Tue, 4 Oct 2011 16:31:48 -0400

> And by the way, in both of these cases, even supposing that we did change the DHCP protocol in the way that's been proposed, how would the DHCP server know that the device was connecting through a…

And how does the host, after receiving the new URI from its DHCP client, notify all the holders of that URI that the URI has changed?

> Right, so I would be curious to hear from other DHC working group members as to whether they have an opinion on whether the DHCP protocol should be extended with an additional lifetime on geopriv U…

I don't think it's acceptable to extend the DHCP specification and state machine to include an additional lifetime on geopriv URIs for a couple of reasons:

* in the specific case, the change doesn't solve the problem
* in the general case, forcing the recoding of the core code in DHCP clients and servers to accommodate this new option is inappropriate

I- Ralph

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 04 Oct 2011 15:57:47 -0500

At 03:31 PM 10/4/2011, Ralph Droms wrote:

> > Interesting.   So they are willing to take a solution that 
> doesn't fix the problem, but reject a solution that does fix the 
> problem?   They can certainly fly in the face of reason like this 
> if they want, but that's not a good reason to change the way the 
> DHCP protocol works.
> >
> > This is actually the same as the previous question.   Even if 
> they were to use DHCP, a lifetime on the address wouldn't actually 
> solve the stated problem, because again the device needs to notice 
> that it's changed cells.
> >
> > And by the way, in both of these cases, even supposing that we 
> did change the DHCP protocol in the way that's been proposed, how 
> would the DHCP server know that the device was connecting through a 
> different access point or cell tower?
>
>And how does the host, after receiving the new URI from its DHCP 
>client, notify all the holders of that URI that the URI has changed?

I'm a little twisted around, and not completely following your 
question. Are you asking how does the host inform remote hosts that 
the URI it sent previously is no longer good or needs to be replaced?
         - Answer - it needs to send the new URI to all the
           remote hosts again (each time), which IMO defeats
           the purpose, but this is what Geopriv wanted

> >
> >> The DHC WG stating there is a problem with the Valid-For field 
> within this document is something concrete that the (Geopriv) 
> chairs would need to address with and into DHC, IMO.
> >
> > Right, so I would be curious to hear from other DHC working group 
> members as to whether they have an opinion on whether the DHCP 
> protocol should be extended with an additional lifetime on geopriv 
> URIs.   Bear in mind that all DHCP clients would have to be 
> modified to support this feature.
>
>I don't think it's acceptable to extend the DHCP specification and 
>state machine to include an additional lifetime on geopriv URIs for 
>a couple of reasons:
>
>* in the general case, forcing the recoding of the core code in DHCP 
>clients and servers to accommodate this new option is inappropriate
>
>I- Ralph

Thanks - I think this is why Robert asked the experts on DHCP.

Other comments, concerns or questions?

James

---

From: Ralph Droms <[email-masked]>
Date: Tue, 4 Oct 2011 17:01:38 -0400

On Oct 4, 2011, at 4:57 PM 10/4/11, James M. Polk wrote:

> I'm a little twisted around, and not completely following your question. Are you asking how does the host inform remote hosts that the URI it sent previously is no longer good or needs to be replaced?

...and I may have missed this from the draft or other background: does the host maintain a list of all other hosts to which it has sent the URI so it can update those hosts?

...which, as you say, seems to defeat the whole purpose of a "permanent" URI.

- Ralph

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 04 Oct 2011 17:46:32 -0500

At 04:01 PM 10/4/2011, Ralph Droms wrote:

> >> >> I shortened the bullet, but what you say above is part of 
> what I suggested (i.e., needing a trigger upon change of an AP), 
> but that didn't satisfy the discussion in Geopriv.
> >> >
>...and I may have missed this from the draft or other background: 
>does the host maintain a list of all other hosts to which it has 
>sent the URI so it can update those hosts?

that would be something the specific conveyance (of the URI) 
applications would need to track, if they wanted to. There's no such 
text in the draft about this.

>...which, as you say, seems to defeat the whole purpose of a "permanent" URI.

my view was that the client would get a location URI, pass it around 
or dereference it via another local protocol, and have "the system" 
or "the network" where the client was track where the client was and 
change the information at the record the URI pointed to - without the 
need for the client to track or be aware of location changes. This 
seemed easiest for me.

Geopriv wanted a new URI sent to the client every time it changes 
location because the location is now considered stale (or bad). 
Further, the URI sent to client A is always different than what is 
sent to any other client, even if on the same AP. Fine, I can live 
with that last part - though others might have an issue with it.

James

>- Ralph
>
> >
> >
> >> >
> >> >> The DHC WG stating there is a problem with the Valid-For 
> field within this document is something concrete that the (Geopriv) 
> >> > Right, so I would be curious to hear from other DHC working 
> group members as to whether they have an opinion on whether the 
> DHCP protocol should be extended with an additional lifetime on 
> geopriv URIs.   Bear in mind that all DHCP clients would have to be 
> >> I don't think it's acceptable to extend the DHCP specification 
> and state machine to include an additional lifetime on geopriv URIs 
> for a couple of reasons:
> >>
> >> * in the general case, forcing the recoding of the core code in 
> DHCP clients and servers to accommodate this new option is inappropriate
> >>
> >> I- Ralph
> >

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Oct 2011 22:53:26 +0000

On Oct 4, 2011, at 6:46 PM, James M. Polk wrote:
Geopriv wanted a new URI sent to the client every time it changes location because the location is now considered stale (or bad). Further, the URI sent to client A is always different than what is sent to any other client, even if on the same AP. Fine, I can live with that last part - though others might have an issue with it.

Yes.   They need a different protocol.   DHCP can't do this.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 04 Oct 2011 18:01:02 -0500

>Yes.   They need a different protocol.   DHCP can't do this.

absolutely, which is why I wrote how to do this using SIP
(http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-conveyance-09.txt)

others wrote how to do this using HTTP (as HELD)

but neither protocol extension (to SIP or HTTP) talked about keeping 
track of which hosts were sent a Location URI for a (semi)automatic 
refresh of the previous URI once it is determined that the location 
information is stale/bad.

James

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Oct 2011 23:12:54 +0000

On Oct 4, 2011, at 7:01 PM, James M. Polk wrote:
but neither protocol extension (to SIP or HTTP) talked about keeping track of which hosts were sent a Location URI for a (semi)automatic refresh of the previous URI once it is determined that the location information is stale/bad.

DHCP doesn't do that either.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 04 Oct 2011 23:10:47 -0500

At 06:12 PM 10/4/2011, Ted Lemon wrote:
>>but neither protocol extension (to SIP or HTTP) talked about 
>>keeping track of which hosts were sent a Location URI for a 
>>(semi)automatic refresh of the previous URI once it is determined 
>>that the location information is stale/bad.
>

nope, it doesn't