Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI)
draft-ietf-geopriv-dhcp-lbyr-uri-option-19

Summary: Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.

(Ralph Droms) Discuss

Discuss (2013-02-06 for -18)
1. (From Ted Lemon's review)  In section 2.5:

  o The Valid-For Option MUST NOT be sent from a server, and received
    by a client, without an accompanying Location URI Option.

This places special processing requirements on the DHCP server—it
would be as if an RFC said "for A records within the ORG. zone, the
DNS server MUST NOT return IP addresses within the 128.45 class B
network, which belongs to a commercial entity."

Just take this text out.

2. (Also from Ted) I would replace this text:

  The Valid-For Option offers no meaningful information to a client
  without an accompanying Location URI Option, and might be
  misunderstood or misapplied, therefore

  o The Valid-For Option MUST NOT be sent from a server, and received
    by a client, without an accompanying Location URI Option.

  o A client receiving a Valid-For Option without a Location URI
    Option MUST ignore the Valid-For Option.

  o The Valid-For Option MUST only be considered in relation to the
    Location URI Option. It has no other purpose in DHCP then in
    relation to the Location URI (i.e., there is no other Option in
    DHCP to which it has meaning).

  o The Valid-For Option MUST NOT cause any error in handling the
    Location URI, i.e., if not understood, it MUST be ignored.

  o Servers MUST assume that clients will overwrite any existing,
    previously sent values of Location URI Option and/or Valid-For
    Option.

  o Clients MUST overwrite any existing, previously sent values of
    Location URI Option and/or Valid-For Option when receiving the
    next instance of either Option.

With this:

   The Valid-For Option offers no meaningful information to a client
   without an accompanying LocationURI Option.  Clients receiving a
   Valid-for option without an accompanying Location URI option SHOULD
   silently ignore this option.  Valid-For options relate specifically
   to Location URI options within the same DHCP message, and do not
   apply to Location URI options received in other DHCP messages.

3. I'm writing this after Brian posted his review and we've started a
conversation about separating the LocationURI and Valid-For options.
There may have been some miscommunication about whether the Valid-For
option could be included in the LocationURI option.  I'll make the
suggestion that the Valid-For life be added as an initial 32-bit
fixed-size field at the beginning of the LocationURI option, with the
special value 0 meaning "no expiration time".

4. (Also from Ted) In section 3:

  It is RECOMMENDED to avoid building URIs, with any parameters,
  larger than what a single DHCP response can be.  However, if a
  message is larger than 255 bytes, concatenation is allowed, per 
  RFC 3396 [RFC3396].

You should pick one position or the other.   Either:

   DHCP servers MUST NOT send URIs longer than 255 bytes.

or:

   The LocationURI option is a concatenation-requiring option as
   described in "Encoding Long Options in DHCPv4" [RFC3396], section
   4.   DHCP clients implementing this specification must also
   implement RFC3396. 

5. The first few paragraphs of section 3 are DHCPv4-centric (and the
message names aren't given accurately).  This text should be edited
to discuss both DHCPv4 and DHCPv6 explicitly.  

6. The second paragraph of section 3 could be read to imply that a
server might put a Location URI option in a separate (additional)
message to a client.  That's not how DHCP works.  All the options have
to fit in a single response (DHCPOFFER, DHCPACK for DHCPv4, Advertise
or Reply for DHCPv6).  The fourth paragraph is potentially confusing
as well, without specifying if the Location URI option is a
concatenating option.  Does "subsequent LocationURI Options" refer to
option within one DHCP message or in distinct DHCP messages?

7. (From Ted Lemon's review) I'm not sure that the way you've
specified IANA considerations will work.   Normally we put text in the
option definition that's replaced by the RFC editor once the option
code has been assigned, like this: 

+----------------+---------+--------------------+
| OPT_LURI4      | len     |      payload       |
+----------------+---------+--------------------+

option-code: OPT_LURI4 (TBD)

This gives the RFC editor a place to put the option code inline.
Rather than just following this recommendation, I would look at some
existing examples.  For example, compare section 3 here:
http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-relay-supplied-options-09
to section 3 here: http://tools.ietf.org/html/rfc6422 and feel free to
plagiarize the IANA considerations section from the draft (not the
RFC!).

Then in the IANA considerations section, you need to say:

The IANA is requested to assign option codes for OPT_LURI4 and
OPT_LURIVALID4 from the BOOTP Vendor Extensions and DHCP Options
registry at
http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xml.
(You also need to say what to put in the Length and Meaning fields;
for LURI, I think it's N, and for LURIVALID it's probably 4.)

The IANA is requested to assign option codes for OPT_LURI6 and
OPT_LURIVALID6 from the DHCP Option Codes registry at
http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml.
(You don't need length and meaning fields for these—we eliminated that
in the DHCPv6 option registry.)
Comment (2013-02-06 for -18)
No email
send info
1. The last paragraph of section 2.5 might be more clearly written as

   It is RECOMMENDED that the Valid-For lifetime always be greater
   than the expected maximum time before the DHCP client will contact
   the DHCP server as part of its normal operation.  Otherwise, there
   is a possibility that the host will not have a valid LocationURI
   for the interval between the Valid-For life expiration and the 

2. (From Ted Lemon's review) You should really give the valid-for
option a name that references the location URI option—lURI valid-for,
or something like that.   This will minimize confusion for people
reading the option registry. 

3. For consistency, use "LocationURI" or "Location URI" throughout the
document.

Editorial suggestion for organizing the document:

Paragraphs 1-4 and (perhaps) 9 (beginning with "This Option is used
only...") would fit better with section 2.5, which would be better
titled "DHCP Operational Considerations".  Section 3 should be
retitled something like "URI, URL and LS considerations".

(Stephen Farrell) Discuss

Discuss (2013-02-25)
-19 doesn't seem to make changes related to this

1) I suspect there's an unfounded assumption built in to this
draft (and plenty of other IETF work) that runs counter to
good privacy practices and current reality. 

The maybe unfounded assumption: Applications running on a
host can be considered to be acting in the interests of the
end-user or administrator of that host.  

If the above description of today's reality is true, (and I
think it is), then there is a missing privacy consideration
here which is that Targets or DHCP clients MUST provide the
end-user or administrator a way to override the actions that
applications might otherwise make related to the use of these
URLs. (In fact, I suspect this will be done anyway, but it'd
still be good to impose that requirement here regardless.)

2) RFC 6753 distinguishes between an authorization by
possession model and a model where (real:-) authorization can
be done via access control done during the HTTP exchange to
re-reference the URL. I would argue that only the latter
model ought be supported here since anyone can send a DHCP
request and see the associated response and (some) wireless
networks can span large areas so a bad actor can learn more
in seeing such a response. That also raises the question as
to what HTTP authentication and access controls a client
using these URIs MUST support. (I see that 3.1 says that the
"possession model" aka supposedly secret URI values, is the
default, but no justification is given for that.)

3) The intro (3rd last para) seems to suggest that home
routers be configured to set these options in responses but
says nothing about privacy. Personally, I think any such
router configuration would for privacy reasons be REQUIRED to
be off by default and only turned on if the user wishes.  I
can see that other opionions would be reasonable and have no
doubt that others will have other opinions. Did the WG
discuss that, if so, got a pointer to the archive?  If not,
maybe either drop the example or add some WG consensus text
about privacy for that case. 

4) Why does this not provide an option for the DHCP client to
control the LS' behaviour? Can you point me at or summarise
the WG discussion of that? I'm a bit surprised about that not
being done, since I'd have thought it'd be good for both
privacy sensitive folks and their opposites (if you know what
I mean). While we ought not provide options for fun, this one
would seem quite reasonable and would seem to provide support
for those who do and don't care about privacy at the same
DHCP relay/server. (I note 3.1 says this is out of scope, but
I don't see why.)

5) Does repeated use of the same value for a URI constitute
identity information? Arguably it does, given that use of
such URIs will be correlated with identity information. The
"MUST NOT reveal" in section 3 5th para if interpreted
strictly seems very onerous. It may be better to have a
positive MUST statement about peudo-randomness and
unpredicatability. 

6) How does the MUST NOT from discuss point 5 match the idea
that the location URI "indicate the residence's civic
address"? That seems plainly contradictory to me. Could be
this is just terminology, but I'd like to check.

7) I don't get how the valid URI schemes is in scope here but
the authorization model and other aspects of the
de-referencing UA are not. The DHCP client and server do not
have to do anything with the scheme, which is only relevant
to the de-referencing UA, but that UA also has to support (or
not) TLS or proxy authentication or OAUTH or whatever might
be needed for handling any real authorization.

8) The reliance on DHCP auth (3118) here seems to me to be
entirely bogus. In what circumstances do you expect 3118 to
be used? I think just deleting that reference to an almost
universally unused RFC would give a more accurate picture of
DHCP security. And I'm also unsure what threat is being
countered by 3118 in this context - I'm not sure having a
fake URI provided to the DHCP client is much of a threat.
Comment (2013-02-25)
No email
send info
- I agree with Barry's first discuss point 

- intro: Is the DHCP client really the Geopriv target? I
think that'd be better stated as the system on which the DHCP
client is running is the Geopriv target.

- intro: you call out the advantages of indirection, but in
fairness you should also admit the disadvantages, which might
include extra round-trips and infrastructure and additional
exposure of possible private information (current location).

- intro: p3, 3rd para: talking about UAs and DHCP clients as
if they were the same seems wrong, and I think this is done
here. The former is an application thing and the latter a
system thing.

- intro, p4, maybe expand LCI on 1st use

- 2.1, don't you need a reference to RFC 3986 for URI
encoding?

- section 3, 2nd last para: s/deference/de-reference/ I
assume:-)

- section 5: critical decisions will never be made on the
value of the URIs, but rather on the location value (when
renders the non-use of 3118 irrelevant I'd say)

- section 5: Saying that someone else ought look at 3552 in
your security considerations is bogus. The authors of this
document should do that here if its needed. In this case the
"that" is sending the location URI over a network between a
DHCP relay and DHCP server I guess.

(Barry Leiba) Discuss

Discuss (2013-02-27)
Updated for -19:

POINT 1:

I've expressed a basic problem I have with getting these URIs via insecure DHCP, and I'll refine that comment here, based on discussion that's so far been had.

Recognizing that in many cases getting URIs this way is an improvement over getting the location information itself, I'll note that that's not always true: the actual LI is a one-time thing, while the location URI can be dereferenced multiple times during its valid period, potentially allowing a snooper to track a moving user over time.

The general point is that a location URI has to be protected from snooping, protected from unauthorized use if it's snooped, or both.  Given that this can't do the former over DHCP, it needs to address the latter issue.  If one gets a URI that can only be used by an authorized entity, we're in much better shape.

That probably means a change to the Introduction to explain the situation, and something in the Security Considerations that addresses use of secure URIs (https or sips, rather than http or sip) and authentication on dereferencing.  I wouldn't want MUSTs here, but strong recommendations to secure this stuff.  I'm looking for something that makes the exposure clear and advises the use of acceptable mechanisms to protect the information, most likely as SHOULD.  Then if you think exposing your subscribers' location information is acceptable, that's between you and your subscribers.

In my conversation with James about this, James mentioned RFC 5606.  I'll note that, while 5606 is not addressing the same thing (5606 is primarily about dealing with "retransmissions", and its advice is only in that context), it actually does support the sorts of things I'm saying (see Section 2, paragraph 5, and Section 3.3.2).

POINT 2:

-- Section 5.3 --

Thanks for fixing the IANA Considerations section; this all now seems quite clear.  I have one question about the new registry:

Why did the working group select IETF Review for the registration policy? Did the working group discuss this? IETF Review requires an IETF-stream RFC (Standards Track, BCP, Informational, or Experimental), and is a fairly high bar. Why does the working group think that Expert Review is not appropriate for this registry?

(Note that I am *not* expecting you to just change this in response to my question.  I want to make sure we have the discussion.)
Comment (2013-02-27)
No email
send info
Updated for -19:

-- Section 2.3 --

   o Clients SHOULD be expected to have to request the Location URI
     Option from servers. Although local policy can have servers
     perform an unsolicited push of a Location URI Option to a client.

"SHOULD be expected to have to"?  That's pretty odd, and I don't think the whole paragraph is clear.  Does this reflect what you're trying to say?:

NEW
   o Clients will normally request the Location URI Option explicitly,
     though servers can include the option without such request,
     according to local policy/configuration.
END

(I don't think 2119 key words are needed there, because there are no interoperability issues involved.)

   Applications on a client can use the Location URI (value) until the
   Valid-For value reaches zero. If there is no Valid-For Option value,
   then the counter did not ever start (a null value), and applications
   on a client continue to use the Location URI value until given a new
   Location URI Option  (with or without a Valid-For value) which
   overwrites any previous Location URI and Valid-For Option values.

I know what you're saying here, but the Valid-For value is a fixed thing that's sent by the server, not something that, by itself, will ever reach zero.  So I think you need to say it a different way, and one that doesn't assume a particular implementation mechanism.  A number of the subsequent bullets also seem confused in similar ways.  Let me try a proposal to replace all of them (including my above proposal here):

NEW
2.3 Rules for the LocationURI Option

   The following rules apply to the LocationURI Option:

   o Implementation of the LocationURI Option is REQUIRED on the DHCP
     server and client.

   o The LocationURI and Valid-For values in a newly received
     LocationURI Option always replace any values received earlier.

   o A Valid-For value of zero means that the LocationURI can be
     used indefinitely (until it is replaced by a new LocationURI
     Option).

   o A LocationURI can be used until the time represented by the
     Valid-For value, or until it is replaced. It MUST NOT be used
     beyond those limits.

   o It is important that server implementations not send a
     LocationURI that is no longer valid.

   o It is important that client implementations discard any
     LocationURI that is no longer valid.  Retaining invalid URIs
     in memory can lead to privacy exposure.

   o Clients MUST NOT trigger an automatic DHCP refresh on expiry
     of the Valid-For timer; rather, they MUST follow normal DHCP
     mechanics.

   The following apply to setting the Valid-For value relative to
   the DHCP lease time:

   o If the Valid-For value is set to be shorter than the DHCP lease
     time, the client will not have a valid URI for its location
     until the lease refresh, leaving a gap in coverage.  
     
   o If the Valid-For value is set to be longer than the DHCP lease
     time, a wayward application on the client could divulge the
     location URI after it is no longer valid, in violation of the
     rules above.

   o Servers SHOULD, therefore, set the Valid-For value to match the
     DHCP lease time as closely as possible.
END

Do you think that works?  If not quite, tweak as appropriate.

-- Section 4.2 --

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

I suggest this instead:

NEW
   URIs carried by this DHCP Option MUST have one of the URI schemes
   in the "Valid Location URI Schemes" registry (see Section 5.3).
   The initial schemes, registered here, are these:
END

I also suggest that the registrations in Section 5.3 use a reference of "[this document], Section 4.2", so that people can quickly find where this is discussed.

(Ted Lemon) Discuss

Discuss (2013-03-30)
Section 2.3 of this document significantly modifies the DHCP protocol, to the extent that if the language in this section remains, it would be necessary to say that this document updates RFC3315 and RFC2131.   Updating RFC3315 and RFC2131 is not part of the geopriv charter; if indeed the author intends to update these RFCs, this document would need to be moved to the DHC working group and would need to become a DHC working group document, and would need to pass last call in that working group (DHC working group /is/ chartered to extend the DHCP protocol).

Normally option specifications do not update RFC3315, RFC2131 or RFC2132 because they are purely additive.   The reason that the text in section 2.3 is a problem is that it doesn't document a new option—it documents new _behavior_ for DHCP servers and clients.   It is this that is out of scope for geopriv work.

To illustrate, consider the following text:

  o Implementation of the Location URI Option is REQUIRED on the DHCP	
     server and client.

This updates the DHCP protocol by requiring that DHCP servers and clients implement this option; ordinarily implementation of new options is optional, and when done, is done by simply adding some new configuration boilerplate to the server configuration, and maybe a post-processing script on the client.

   o Clients SHOULD be expected to have to request the Location URI
     Option from servers. Although local policy can have servers
     perform an unsolicited push of a Location URI Option to a client.

This updates the DHCP protocol to supersede the statement in RFC3315 that DHCP servers MUST NOT send unsolicited options.   It skates the ragged edge of updating RFC2131 as well; RFC2131 does not forbid sending unsolicited options, but it doesn't require it either.

   o Servers SHOULD set the Valid-For timer to that of the lease
     refresh, or bad things can happen.

I talk about this below in the comments as well, but my DISCUSS-level objection to this is that since lease times are a negotiation, not a hard configuration on the server, in order to satisfy the SHOULD above, the server has to have special code for this option that derives the Valid-for time from the lease time.   This is another protocol change to DHCP, and hence out of scope for this document.   You haven't actually stated it as a requirement, so I suppose you could argue that it's the implementor's problem, but I think that would be splitting hairs—I think you really have updated RFC3315 and RFC2131 with this language.
Comment (2013-03-30)
No email
send info
   o A Location URI Option with a non-zero Valid-For field MUST NOT
     transmit the Location URI once the Valid-For field counts down to
     zero.

I don't know what the object of the MUST NOT here is, which is a problem in itself.   Also, the multiple meanings for a zero value are confusing here—it might be easier to state this in terms of calculating an absolute end to the valid lifetime by adding the valid time option to the current time.   Then you can just talk about when the recorded expiration time is earlier than the present time, and not confuse the different meanings of zero.

   o Receipt of the Location URI Option containing all zeros in the
     Valid-For field MUST NOT cause any error in handling the Location
     URI.

What is the object of the MUST NOT here?   Why is this text necessary since the previous bullet item already says what the meaning of a value of zero in this field is?


   o When the Valid-For timer reaches zero, the client MUST purge any
     location URI received via DHCP from its memory.

This is an implementation detail, and shouldn't be stated with normative language, if indeed it should be stated at all.   I think this is the repeat of the first bullet item in this series, stated a different way.   You shouldn't care how the client handles garbage collection—just what it *does*.   So simply saying that after the Valid-for timer has expired, the client MUST not continue to use the URI should suffice.

   o Clients receiving a Location URI Option start the Valid-For timer
     upon receipt of the DHCP message containing the Option.

   o Clients MUST NOT trigger an automatic DHCP refresh on expiry of
     the Valid-For timer; rather, they MUST follow normal DHCP
     mechanics.

I feel uncomfortable with this, and I think it's because you're really specifying implementation again rather than behavior.   If you take my advice about calculating absolute end times rather than having a countdown timer that triggers an event, I think you could really simplify this.

I realize that the second item is actually a response to a comment I made, but I would rather you said something like this:

  o The Valid-For time is independent of the DHCP client renewal
     process; if the URI's validity ends before the lease renews, the
     client will simply not be able to provide a URI during the period
     between the end of the valid time of the URI and the renewal of
     the DHCP lease.

That segues into this paragraph, which I am having difficulty making sense of:

   If the Valid-For timer is set to expire before the lease refresh,
   the client will not have the ability to hand out its location until
   the lease refresh, inadvertently allowing a gap of coverage. If the
   Valid-For timer is set to expire after the lease refresh, some
   wayward application on the client can divulge that location URI
   after it is no longer valid, meaning the location could be stale or
   just plain wrong.

This is why I argued that the location URI shouldn't have a separate lifetime.   You get bad behavior when it's shorter than the lease, and you get bad behavior when it's longer than the lease.   And it's difficult to even say what the bad behavior will be:

   o Servers SHOULD set the Valid-For timer to that of the lease
     refresh, or bad things can happen.

If servers SHOULD do this, what's the point of having a Valid-for timer at all?   What are the bad things that can happen?   What is the edge case that justifies a SHOULD here instead of a MUST?

(Pete Resnick) Discuss

Discuss (2013-02-28)
Section 2.3 really needs a lot of work. [There are a couple of editorial points embedded in here that are not things I need to DISCUSS; I've set those off in square brackets.]

OLD
   o Implementation of the Location URI Option is REQUIRED on the DHCP
     server and client.

I know you don't mean that as written. As written, it says that all DHCP servers and clients are now required to implement this option. If you really meant this, you'd need an "Updates: 2131", and I'm quite sure that's not right. I suspect you might mean something like: "The DHCP Location URI Option MUST NOT be used unless both the server and the client support it." But I don't think that's necessary. My recommendation is to simply strike this sentence.

OLD
   o Clients SHOULD be expected to have to request the Location URI 
     Option from servers. Although local policy can have servers 
     perform an unsolicited push of a Location URI Option to a client.

Aside from the second sentence being ungrammatical, this is overall not clear. Do you mean:

NEW
   o Clients normally send explicit requests for the Location URI
     Option. Servers SHOULD NOT send unsolicited Location URI
     Option responses to a client. 

? I'm not even sure if that SHOULD NOT is correct. What are you trying to get across in this bullet?

OLD
   Applications on a client can use the Location URI (value) until the 
   Valid-For value reaches zero. If there is no Valid-For Option value,
   then the counter did not ever start (a null value), and applications
   on a client continue to use the Location URI value until given a new
   Location URI Option  (with or without a Valid-For value) which 
   overwrites any previous Location URI and Valid-For Option values.

[The first sentence is goofy, though I know what you mean: The "Valid-For value" is never going to "reach zero"; what you mean is: 

NEW
   Applications on a client can use the returned Location URI for the
   number of seconds specified in Valid-For from the time it was
   received by the client.
 ]
  
But the second sentence is completely unwieldy and not clear. (Zero is not a "null value".) Simplify:

NEW
   If the Valid-For value is zero, it indicates that there is no time
   limit on the use of the returned Location URI. It may be used until
   the server returns a new Location URI.

OLD
   o Receipt of the Location URI Option containing all zeros in the 
     Valid-For field MUST NOT cause any error in handling the Location 
     URI.

I don't know what that is supposed to mean. Why do you think you need to call out that I MUST NOT cause an error in *any* event?

OLD
   o When the Valid-For timer reaches zero, the client MUST purge any 
     location URI received via DHCP from its memory.

Aside from the "timer reaches zero" thing, I have to say: Baloney. I will *not* be purging any memory because you tell me to in this document, thank you very much. You can tell me not to use the thing, but you can't tell me how I have to do memory garbage collection. Please delete this.

OLD
   If the Valid-For timer is set to expire before the lease refresh, 
   the client will not have the ability to hand out its location until 
   the lease refresh, inadvertently allowing a gap of coverage. If the 
   Valid-For timer is set to expire after the lease refresh, some 
   wayward application on the client can divulge that location URI 
   after it is no longer valid, meaning the location could be stale or 
   just plain wrong.

[In the first sentence, change "hand out" to "use". Possible also change "the client" to "client applications". ]

The second sentence seems completely bogus to me: If the Valid-For time is longer than the lease time, it's the server's responsibility to hand me back the same URI when my lease expires. That URI *is* valid for the Valid-For time, and can never be stale or wrong. Therefore:

OLD
   o Servers SHOULD set the Valid-For timer to that of the lease 
     refresh, or bad things can happen.

NEW
   o Servers SHOULD set Valid-For to greater than or equal to the lease
     refresh, or bad things can happen.
     
Section 4.2: "MUST have one of the following URI schemes"? Are you saying I need to write an update to this document if I want to use a different URI scheme for location information? Similarly:

Section 5.3: "IETF Review"

This all seems very heavy handed. Are we really in fear of people adding to this registry willy-nilly? Would not "Expert Review" or "Specification Required" not perfectly well suffice? Could we therefore not change 4.2 to say, "MUST be values registered in the Valid Location URI Schemes registry (defined in section 5.3)"?
Comment (2013-02-28)
No email
send info
I agree with Barry that it would be good to have some further justification in the Intro for the usefulness of this mechanism.

Section 2.1:

OLD
   Valid-For:    The time, in seconds, the LocationURI is to be 
                 considered valid for dereferencing. The Valid-For is 
                 always represented as a four-byte unsigned integer.

I would add "in network byte order" just to be clear. Also: I believe that zero in this field means that there is no expiry; the URI is valid until replaced. You should say that here, not just in 2.3. So:

NEW
   Valid-For:    The time, in seconds, the LocationURI is to be 
                 considered valid for dereferencing. The Valid-For is 
                 always represented as a four-byte unsigned integer
                 in network byte order. A value of 0 (zero) indicates
                 that there is no valid time specified; the URI is
                 valid until it is replaced.

Section 2.3:

OLD
   o A Location URI Option with a non-zero Valid-For field MUST NOT 
     transmit the Location URI once the Valid-For field counts down to 
     zero.

That's already said above. And "count down" assumes an implementation choice. (Me, I'd add the number of seconds to the current time to get expiration time and then compare it to current time thereafter.) But, it's redundant. Delete.

OLD
   o A received Location URI Option containing all zeros in the 
     Valid-For field means that Location URI has no lifetime, and not 
     "no lifetime left". All zeros in the Valid-For field equates to a 
     null value.

Redundant. Delete.

OLD
   o Clients receiving a Location URI Option start the Valid-For timer 
     upon receipt of the DHCP message containing the Option.
     
I had something like this in my replacement above, so now redundant.

Section 3: s/identity information/identifying information

Section 4.1 seems like a security consideration. Perhaps move it to section 6?

(Martin Stiemerling) Discuss

Discuss (2013-02-04 for -17)
I have no general objections to this draft, but multiple points to be discussed. However, most of my DISCUSS worthy issues are already covered by parts of Barry's, Stephen's, and Sean's DISCUSS. 

There is only a single point left:

Section 2.5, paragraph 11:

>    o Clients MUST overwrite any existing, previously sent values of
>      Location URI Option and/or Valid-For Option when receiving the
>      next instance of either Option.

  If a host has multiple interfaces that are used concurrently and the host receives the location URI from multiple DHCP server, how is this handled? This information is handed over to some application that probably doesn't care too much about multiple network locations. However, this is something that should be at least mentioned and discussed.
Comment (2013-02-04 for -17)
No email
send info

Here are a few points for your consideration:

Section 7., paragraph 1:

>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in [RFC2119].

  This part isn't right here, as it is not part of the ToC, but also
  not part of any section. Move it to the introduction.


Section 1., paragraph 6:

>    If the client was provided a location URI reference to retain and
>    hand out when it wants or needs to convey its location (in a
>    protocol other than DHCP), a location URI that would not change as
>    the client's location changes (within a domain).Scaling issues

  This sentence is not complete, isn't it? Or I cannot read and understand the meaning of it. 


Section 2.1, paragraph 4:

>    Length=XX:    The length of this option, counted in bytes - not
>                  counting the Code and Length bytes. This is a variable
>                  length Option, therefore the length value will change
>                  based on the length of the URI within the Option.

  I would include a pointer to the datagram length discussion in
  Section 3, just for completeness and to be sure that everybody
  understands the issue.


Section 2.2, paragraph 5:

>    option-len:  The length of this option, counted in bytes - not
>                 counting the option-code and option-len bytes. This is
>                 a variable length Option, therefore the length value
>                 will change based on the length of the URI within the
>                 Option.

  I would include a pointer to the datagram length discussion in
  Section 3, just for completeness and to be sure that everybody
  understands the issue.


Section 2.5, paragraph 2:

>    o Implementation of the Location URI Option is mandatory on the DHCP
>      server and client, per this specification.

  'mandatory' is not a term per RFC 2119. Should this read 'MUST be
  implemented by the client and the server if they support <this-RFC>',
  as you use 'OPTIONAL' just one down?


Section 2.5, paragraph 4:

>    o The Location URI Option MUST be sent from a server, and received
>      by a client with or without an accompanying Valid-For Option.

  Doesn't this mean more 'The Location URI Option MUST be only be
  sent by a server. Clients MUST NOT sent it.'


Section 2.5, paragraph 6:

>    o The Valid-For Option MUST NOT be sent from a server, and received
>      by a client, without an accompanying Location URI Option.

  A proposal to improve readability: 'The Valid-For Option MUST be sent
  by a server together with an accompanying Location URI Option.' I
  would remove the client part, as it is anyhow described below. The
  client will receive any unwanted option anyhow, but it ignores it
  later on during the processing.


Section 3396, paragraph 8:

>    This Option is used only for communications between a DHCP client
>    and a DHCP server.  It can be solicited (requested) by the client,
>    or it can be pushed by the server without a request for it.  DHCP
>    Options not understood MUST be ignored [RFC2131].  A DHCP server

  I would make this a single paragraph, to improve readability, i.e., split it from the following rest..


Section 3396, paragraph 11:

>    In the case of residential gateways being DHCP servers, they usually
>    perform as DHCP clients in a hierarchical fashion up into a service
>    provider's network DHCP server(s), or learn what information to
>    provide via DHCP to residential clients through a protocol, such as
>    PPP.  In these cases, the location URI would likely indicate the
>    residence's civic address to all wired or wireless clients within
>    that residence.

  Not completely true, if there is also a VPN (or tunnel in general)
  gateway in that premise. How about: 'In these cases, the location
  URI would likely indicate the residence's civic address of the
  residential gateway.'


Section 3.2, paragraph 4:

>    o Section 3.3 IANA registers acceptable location URI schemes (or
>      types) for use by this specification. Clients MUST reject URI
>      schemes not currently registered in IANA.

  Isn't this 'MUST reject' a bit too strong? Given that somebody
  could have a new URI scheme, or one that is not public? A 'SHOULD'
  would be good enough.

(Richard Barnes) Yes

(Robert Sparks) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

Comment (2013-01-29 for -17)
No email
send info
There a couple of places where you use the work "deference" when I think you mean "dereference"

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

Comment (2013-02-04 for -17)
No email
send info
This document is scrutinized by Barry, Sean, Martin, and Stephen. I has enough attention, and I trust those ADs will do the right thing.

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

(Brian Haberman) (was Discuss) No Objection

Comment (2013-02-25)
No email
send info
Thanks for addressing my DISCUSS points...

(Sean Turner) (was Discuss) No Objection

Ignas Bagdonas No Record

Deborah Brungard No Record

Ben Campbell No Record

Alissa Cooper No Record

Spencer Dawkins No Record

Benjamin Kaduk No Record

Suresh Krishnan No Record

Warren Kumari No Record

Mirja Kühlewind No Record

Terry Manderson No Record

Alexey Melnikov No Record

Eric Rescorla No Record

Alvaro Retana No Record

Adam Roach No Record

Martin Vigoureux No Record