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.