[Geopriv] Two DHCP options in draft-ietf-geopriv-dhcp-lbyr-uri-option

[Alissa Cooper <[e-mail]>]

Hi all,

As you've seen on the list, Ted Lemon has raised a number of issues regarding draft-ietf-geopriv-dhcp-lbyr-uri-option during IETF last call, including the one below about using separate options for the URI and Valid-For values instead of having them share one option with different Luritypes. The argument is that splitting these into two options reduces complexity on the server side, although it may make Valid-For less likely to be implemented on the server and/or less likely to be accessible by applications on the client end.

The current draft contains the following text that limits each client to one URI:

It should be expected that clients will overwrite any previous
  Option values when receiving a new instance of that Option number.

So while multiple URIs are not supported, the one-option-with-Luritype format makes it possible for a future update to the spec to add support for multiple URIs if so desired. Splitting the URI and Valid-For into two options will ensure that multiple URIs per client will not be possible in the future. 

Before making this change in the draft, we wanted to give folks in the WG the opportunity to raise objections if they have them. If you have a problem with splitting the URI and Valid-For into two options, please send a mail to the list by July 5, 2012.

Thanks,
Alissa

Begin forwarded message:

> From: Ted Lemon <[e-mail]>
> Date: May 31, 2012 4:43:11 PM EDT
> To: [e-mail]
> Cc: "James M. Polk" <[e-mail]>, Robert Sparks <[e-mail]>, Alissa Cooper <[e-mail]>
> Subject: Re: Last Call: <draft-ietf-geopriv-dhcp-lbyr-uri-option-15.txt> (Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI)) to Proposed Standard
> 
> There are still a few problems with this draft.   The first is that it uses a nonstandard and somewhat odd encoding to deliver the URI and Lifetime values.   These should simply be delivered as separate options, leaving out the whole Luritype complication.    The argument might be raised that the Luritype field provides some sort of future-proofing, but this future-proofing can as easily be attained with another DHCP option code, so it's unnecessary.