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.
