Subject: Re: [Geopriv] 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

From: Alissa Cooper <[email-masked]>
Date: Fri, 22 Jun 2012 15:59:35 -0400

Hi Ted,

Some responses inline.

On May 31, 2012, at 4:43 PM, Ted Lemon wrote:

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

My understanding is that the option is encoded this way both for extensibility and because the Valid-For parameter is solely a property of the URI. Surely this is not the only instance of a DHCP option with a sub-option? 

It may have been before I was paying attention, but I get the impression that related ground has already been trod in DHC, given that it also came up in GEOPRIV. http://www.ietf.org/mail-archive/web/geopriv/current/msg08451.html

> 
> Secondly, this text ought to be expanded:
> 
>> The choice of the Valid-For value is a policy decision for the 
>> operator of the DHCP server.  Like location URIs themselves, it can 
>> be statically configured on the DHCP server or provisioned 
>> dynamically (via an out-of-band exchange with a Location Information
>> Server) as requests for location URIs are received.
> 
> To:
> 
>> The choice of the Valid-For value is a policy decision for the 
>> operator of the DHCP server.  Like location URIs themselves, it can 
>> be statically configured on the DHCP server or provisioned 
>> dynamically (via an out-of-band exchange with a Location Information
>> Server) as requests for location URIs are received.   DHCP server
>> operators are advised not to configure a valid-for lifetime that is
>> greater than half the minimum configured lifetime for DHCP leases,
>> since this could result in stale configuration information on the
>> DHCP client and potential loss of service.
> 

I'm not sure the additional text is necessary given that there is an entire paragraph explaining considerations for servers in setting the Valid-For value. Furthermore, I don't see how "potential loss of service" is possible. We're talking about a URI with an expiration. When it expires, location recipients will no longer have access to the client's location, but it otherwise doesn't affect recipients' ability to use any "service" whatsoever.

> 
> Thirdly, this text is simply wrong, and indeed specifically contradicted by RFC3396:
> 
>>   Per [RFC2131], subsequent LocationURI Options, which are 
>>   non-concatenated, overwrite the previous value.
> 
> I don't think this is a huge problem, but I think the text should say this:
> 
>> It is not meaningful to configure multiple LocationURI options.   DHCPv4 servers and clients conforming to RFC3396 will not permit this; DHCPv6 servers and clients can be configured this way, but the behavior when so configured is undefined.   Therefore, DHCPv6 server operators are cautioned not to configure more than one such option.

Works for me.

> 
> Section 3.2 suggests that options shouldn't contain certain potentially harmful values, but this is a toothless restriction, since an attacker can simply ignore it.   In order for it to be effective, Section 3.2 should insist that DHCP clients reject forbidden URI formats.   Of course, this too is somewhat toothless, since any list of forbidden URI formats will necessarily fail to mention any future potentially harmful URIs that could arise.   It would be better to list which URIs _are_ permitted, and require the client to reject any URI that is not permitted.   The document is already set up to do this, but doesn't _actually_ do it, so fixing this should be quite easy.

In 3.3, I suggest replacing the following:

"This section specifies which URI types are acceptable as a location
   URI scheme (or type) for this DHCP Option:"

with

"URIs carried by this DHCP Option MUST have one of the following URI schemes:"

Thanks,
Alissa

> 
> Sorry for not catching all of this sooner—the previous review of the document was rudely interrupted by the Paris IETF meeting... :)
> 
> Aside from these objections, which I think are easy to address, I have no problem with the document proceeding.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 22 Jun 2012 16:11:28 -0400

> My understanding is that the option is encoded this way both for extensibility and because the Valid-For parameter is solely a property of the URI. Surely this is not the only instance of a DHCP op…

What's in the draft is not suboptions—it's a whole special format requiring new code on all servers that implement it.   Suboptions don't exist in DHCPv6—just encapsulations of regular options, which I don't think make sense here either.

> It may have been before I was paying attention, but I get the impression that related ground has already been trod in DHC, given that it also came up in GEOPRIV. http://www.ietf.org/mail-archive/we…

When the topic of suboptions first came up, it was because I proposed them as an alternative to a complicated internal option structure with lots of special code required in the server to implement.   But given that only one Location URI option is allowed, there's no need for suboptions.

> I'm not sure the additional text is necessary given that there is an entire paragraph explaining considerations for servers in setting the Valid-For value. Furthermore, I don't see how "potential l…

You're right—don't know how I missed that.

> "URIs carried by this DHCP Option MUST have one of the following URI schemes:"

That's just as toothless.   Unless the client MUST reject these options, it MAY accept them.

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 27 Jun 2012 17:27:38 -0400

Hi Ted,

> When the topic of suboptions first came up, it was because I proposed them as an alternative to a complicated internal option structure with lots of special code required in the server to implement…

If we split it into two options, that eliminates the future possibility of supporting multiple URIs per client. So we will need to take this back to the GEOPRIV WG to make sure folks are okay with foreclosing that.

> That's just as toothless.   Unless the client MUST reject these options, it MAY accept them.

Okay, will add MUST reject language.

Alissa

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 27 Jun 2012 17:40:10 -0400

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 <[email-masked]>
> Date: May 31, 2012 4:43:11 PM EDT
> To: [email-masked]
> Cc: "James M. Polk" <[email-masked]>, Robert Sparks <[email-masked]>, Alissa Cooper <[email-masked]>
> 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
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 28 Jun 2012 00:02:14 +0200

> If we split it into two options, that eliminates the future possibility of supporting multiple URIs per client. So we will need to take this back to the GEOPRIV WG to make sure folks are okay with…

The document already says that multiple URIs aren't valid, doesn't it?