> On 12/12/11 2:37 PM, James M. Polk wrote:
>> At 08:47 PM 12/9/2011, Martin Thomson wrote:
>>> 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.
>>
>> 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?
> 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.
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
>>
>> James
>>
>>> 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 <rjsparks@nostrum.com> wrote:
>>> > 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
>>> > _______________________________________________
>>> > 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
