Subject: [Geopriv] Continued discussion of draft-ietf-geopriv-dhcp-lbyr-uri-option on the dhcwg list

From: Robert Sparks <[email-masked]>
Date: Thu, 08 Dec 2011 14:18:25 -0600

Please take a look at
http://www.ietf.org/mail-archive/web/dhcwg/current/msg12238.html

If you have anything to add, or more importantly, if you see something I 
got wrong that you need
to correct, please do so on the dhcwg list.

RjS

---

From: Martin Thomson <[email-masked]>
Date: Sat, 10 Dec 2011 13:47:18 +1100

A good, clear summary.

You didn't mention access control policy, but that's probably OK for
the purposes of the discussion at hand.

On the last paragraph, I think that Richard suggested that there be a
recommendation (though not a 2119 SHOULD) that the expiration be
longer than the lease time.  The only reason being that it's probably
sensible to ensure that a host always has a valid location URI.

--Martin

On 9 December 2011 07:18, Robert Sparks <[email-masked]> wrote:
> If you have anything to add, or more importantly, if you see something I got
> wrong that you need
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 12 Dec 2011 14:37:20 -0600

At 08:47 PM 12/9/2011, Martin Thomson wrote:
>longer than the lease time.

err...

I'm thoroughly confused.

the current WG chair and the AD in the Int area (aka the previous WG 
chair from the WG's inception) both have a fundamental problem with 
the whole idea of more than one lifetime timer (i.e., lease). How can 
anyone here be advocating what they have said needs to go at this late stage?

James

>The only reason being that it's probably

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 12 Dec 2011 15:44:05 -0500

As I understood what Ralph/Ted were saying, they were concerned that a URI expiry would trigger a DHCP refresh, which was not cool.  You don't have that problem if the lifetime is at least the DHCP lease time.

--Richard

On Dec 12, 2011, at 3:37 PM, James M. Polk wrote:

> the current WG chair and the AD in the Int area (aka the previous WG chair from the WG's inception) both have a fundamental problem with the whole idea of more than one lifetime timer (i.e., lease). How can anyone here be advocating what they have said needs to go at this late stage?
> 
> James
>

---

From: Robert Sparks <[email-masked]>
Date: Mon, 12 Dec 2011 14:49:38 -0600

> anyone here be advocating what they have said needs to go at this late 
They (rightfully) have a problem with the lifetime timer affecting the 
_lease_ time (either directly or as a side-effect through making the 
application renew at a time other than it would have under normal DHCP
requirements).

Please read the note I sent to the dhcwg list - the expiry on the 
location url is important information
to the application that will hand out that url. It needs to continue to 
be defined, and there's no reason
to force it to be exactly the dhcp lease time.

I've been talking with Ralph (copied) and I believe we're closer to a 
common understanding that doesn't
involve completely removing the url expiry.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 14 Dec 2011 16:10:58 -0500

On Dec 12, 2011, at 3:49 PM 12/12/11, Robert Sparks wrote:

> They (rightfully) have a problem with the lifetime timer affecting the _lease_ time (either directly or as a side-effect through making the application renew at a time other than it would have under normal DHCP
> requirements).
> 
> Please read the note I sent to the dhcwg list - the expiry on the location url is important information
> to the application that will hand out that url. It needs to continue to be defined, and there's no reason
> I've been talking with Ralph (copied) and I believe we're closer to a common understanding that doesn't

As I understand the requirements through my conversation with Robert, the option could be defined to be compatible with DHCP server design if the LURI in the option can be provided by the server without a real-time reference to some external information source, and if the "valid time" for the LURI does not *directly* affect the lease time expiration.

So, for example, if the LURIs for hosts can be made available to the DHCP server before the requests arrive from those hosts, the DHCP server should be able to handle returning the speific LURI for a host through the DHCP message exchange.  And, if the valid time is used by the client app (presumably the app that manages handing out the LURI to other hosts) as an indication of when to request an Information-request for the LURI, the mechanism would be compatible with DHCP clients.

- Ralph

---

From: Brian Rosen <[email-masked]>
Date: Wed, 14 Dec 2011 16:32:39 -0500

Just so I'm clear:
> 
> And, if the valid time is used by the client app (presumably the app that manages handing out the LURI to other hosts) as an indication of when to request an Information-request for the LURI, the mechanism would be compatible with DHCP clients.
> 
The "Information-request for the LURI" is a DHCP client request to the DHCP server, right?  You are just concerned that this request doesn't (necessarily) request an IP address lease renewal.

If that's it, I see no problem.  We need an explicit lifetime for the L-URI in the return from the request which is totally independent of the IP address lease time.

Brian