Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI)
draft-ietf-geopriv-dhcp-lbyr-uri-option-19
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-10-14
|
19 | (System) | Notify list changed from geopriv-chairs@ietf.org, draft-ietf-geopriv-dhcp-lbyr-uri-option@ietf.org to (None) |
2014-01-24
|
19 | (System) | Document has expired |
2014-01-23
|
19 | Richard Barnes | Insufficient energy to resolve IESG comments. |
2014-01-23
|
19 | Richard Barnes | State changed to I-D Exists (IESG: Dead) from IESG Evaluation::AD Followup |
2013-06-04
|
19 | Richard Barnes | [Ballot Position Update] New position, Yes, has been recorded for Richard Barnes |
2013-03-30
|
19 | Ted Lemon | [Ballot comment] o A Location URI Option with a non-zero Valid-For field MUST NOT transmit the Location URI once the Valid-For field … [Ballot comment] 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? |
2013-03-30
|
19 | Ted Lemon | Ballot comment text updated for Ted Lemon |
2013-03-30
|
19 | Ted Lemon | [Ballot discuss] Section 2.3 of this document significantly modifies the DHCP protocol, to the extent that if the language in this section remains, it would … [Ballot discuss] 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. |
2013-03-30
|
19 | Ted Lemon | [Ballot comment] o A Location URI Option with a non-zero Valid-For field MUST NOT transmit the Location URI once the Valid-For field … [Ballot comment] 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? |
2013-03-30
|
19 | Ted Lemon | Ballot comment and discuss text updated for Ted Lemon |
2013-03-29
|
19 | Ted Lemon | [Ballot discuss] Section 2.3 of this document significantly modifies the DHCP protocol, to the extent that if the language in this section remains, it would … [Ballot discuss] 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. (I will be adding more to this DISCUSS, but I've run out of time and need to save, so please don't feel obligated to respond yet—I'll trigger an email transmission when I'm finished.) |
2013-03-29
|
19 | Ted Lemon | [Ballot comment] o A Location URI Option with a non-zero Valid-For field MUST NOT transmit the Location URI once the Valid-For field … [Ballot comment] 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? |
2013-03-29
|
19 | Ted Lemon | [Ballot Position Update] New position, Discuss, has been recorded for Ted Lemon |
2013-03-13
|
19 | Cindy Morgan | Shepherding AD changed to Richard Barnes |
2013-02-28
|
19 | Pete Resnick | [Ballot discuss] Section 2.3 really needs a lot of work. [There are a couple of editorial points embedded in here that are not things I … [Ballot discuss] 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)"? |
2013-02-28
|
19 | Pete Resnick | [Ballot comment] I agree with Barry that it would be good to have some further justification in the Intro for the usefulness of this mechanism. … [Ballot comment] 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? |
2013-02-28
|
19 | Pete Resnick | Ballot comment and discuss text updated for Pete Resnick |
2013-02-27
|
19 | Barry Leiba | [Ballot discuss] 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 … [Ballot discuss] 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.) |
2013-02-27
|
19 | Barry Leiba | Ballot discuss text updated for Barry Leiba |
2013-02-27
|
19 | Barry Leiba | [Ballot discuss] 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 … [Ballot discuss] 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, BCO, 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.) |
2013-02-27
|
19 | Barry Leiba | [Ballot comment] Updated for -19: -- Section 2.3 -- o Clients SHOULD be expected to have to request the Location URI Option … [Ballot comment] 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. |
2013-02-27
|
19 | Barry Leiba | Ballot comment and discuss text updated for Barry Leiba |
2013-02-25
|
19 | Brian Haberman | [Ballot comment] Thanks for addressing my DISCUSS points... |
2013-02-25
|
19 | Brian Haberman | [Ballot Position Update] Position for Brian Haberman has been changed to No Objection from Discuss |
2013-02-25
|
19 | Stephen Farrell | [Ballot discuss] -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 … [Ballot discuss] -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. |
2013-02-25
|
19 | Stephen Farrell | [Ballot comment] - I agree with Barry's first discuss point - intro: Is the DHCP client really the Geopriv target? I think that'd be better … [Ballot comment] - 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. |
2013-02-25
|
19 | Stephen Farrell | Ballot comment and discuss text updated for Stephen Farrell |
2013-02-24
|
19 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-02-24
|
19 | James Polk | New version available: draft-ietf-geopriv-dhcp-lbyr-uri-option-19.txt |
2013-02-07
|
18 | Tero Kivinen | Request for Telechat review by SECDIR Completed: Has Nits. Reviewer: Chris Lonvick. |
2013-02-07
|
18 | Alexey Melnikov | Request for Telechat review by GENART Completed: Ready with Issues. Reviewer: Alexey Melnikov. |
2013-02-07
|
18 | Amy Vezza | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation |
2013-02-06
|
18 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy |
2013-02-06
|
18 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2013-02-06
|
18 | Ralph Droms | [Ballot discuss] 1. (From Ted Lemon's review) In section 2.5: o The Valid-For Option MUST NOT be sent from a server, and received … [Ballot discuss] 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.) |
2013-02-06
|
18 | Ralph Droms | [Ballot comment] 1. The last paragraph of section 2.5 might be more clearly written as It is RECOMMENDED that the Valid-For lifetime always be … [Ballot comment] 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". |
2013-02-06
|
18 | Ralph Droms | [Ballot Position Update] New position, Discuss, has been recorded for Ralph Droms |
2013-02-06
|
18 | Brian Haberman | [Ballot discuss] Updated after a discussion with Robert... I am having a hard time understanding a few things in this document... 1. Section 3 purports … [Ballot discuss] Updated after a discussion with Robert... I am having a hard time understanding a few things in this document... 1. Section 3 purports to discuss how DHCP will handle this option. However, the text does not contain a sufficient level of detail to ensure interoperability. Additionally, there are operational differences between DHCPv4 and DHCPv6 that are not considered in this section. Is this information supposed to always be included by a server when an address is assigned to a requesting device? Or should this option really only be returned when it is explicitly requested? Here is one example of how this lack of clarity can cause problems. A DHCP client implementation could assume that this option will be returned with any addresses assigned to the device. The server implementation could assume that this option is only returned when a client requests additional information via an INFORM message. I would suggest having a sub-section within section 3 for both DHCPv4 and DHCPv6 that spell out how the DHCP exchanges are to occur. 2. [Removed since the splitting of the information was a recommendation from DHC] 3. Sections 3.1-3.3 are not related to the operation of DHCP. Is there a reason why they are lumped into section 3? 4. The last paragraph of section 2.5 (discussion of values for the Valid-for option) is quite confusing and may actually be wrong. Given the lack of unity in the URI lifetime and the DHCP lease lifetime, shouldn't the guidance simply be that the URI lifetime should not be less than the DHCP lease lifetime? |
2013-02-06
|
18 | Brian Haberman | Ballot discuss text updated for Brian Haberman |
2013-02-06
|
18 | Brian Haberman | [Ballot discuss] I am having a hard time understanding a few things in this document... 1. Section 3 purports to discuss how DHCP will handle … [Ballot discuss] I am having a hard time understanding a few things in this document... 1. Section 3 purports to discuss how DHCP will handle this option. However, the text does not contain a sufficient level of detail to ensure interoperability. Additionally, there are operational differences between DHCPv4 and DHCPv6 that are not considered in this section. Is this information supposed to always be included by a server when an address is assigned to a requesting device? Or should this option really only be returned when it is explicitly requested? Here is one example of how this lack of clarity can cause problems. A DHCP client implementation could assume that this option will be returned with any addresses assigned to the device. The server implementation could assume that this option is only returned when a client requests additional information via an INFORM message. I would suggest having a sub-section within section 3 for both DHCPv4 and DHCPv6 that spell out how the DHCP exchanges are to occur. 2. Why is there a separate option for the lifetime (Valid-for). Since it is a fixed length field, why is it not a part of the LocationURI option? 3. Sections 3.1-3.3 are not related to the operation of DHCP. Is there a reason why they are lumped into section 3? 4. The last paragraph of section 2.5 (discussion of values for the Valid-for option) is quite confusing and may actually be wrong. Given the lack of unity in the URI lifetime and the DHCP lease lifetime, shouldn't the guidance simply be that the URI lifetime should not be less than the DHCP lease lifetime? |
2013-02-06
|
18 | Brian Haberman | [Ballot Position Update] New position, Discuss, has been recorded for Brian Haberman |
2013-02-05
|
18 | Pete Resnick | [Ballot discuss] I am baffled by two things in 2.5: o Implementation of the Location URI Option is mandatory on the DHCP … [Ballot discuss] I am baffled by two things in 2.5: o Implementation of the Location URI Option is mandatory on the DHCP server and client, per this specification. Why is this mandatory? You can't be saying that all DHCP servers are now required to implement this option, can you? o The Location URI Option MUST be sent from a server, and received by a client with or without an accompanying Valid-For Option. I don't understand what this is trying to say that isn't stupidly obvious. As Martin says in his comment, are you simply trying to say that the Location URI MUST NOT be sent by a client? I don't get it. |
2013-02-05
|
18 | Pete Resnick | [Ballot comment] As I said in my reply to Barry's comments, I disagree with Barry's first DISCUSS point. I believe this can be a useful … [Ballot comment] As I said in my reply to Barry's comments, I disagree with Barry's first DISCUSS point. I believe this can be a useful mechanism, but I think some more needs to be said in the intro regarding why it is useful. In addition, there should be some justification in the intro for why this would be at all interesting to fixed location devices (assuming there is one). It seems like passing the actual PIDF-LO instead of a URI would be *more* efficient, if not safer, for fixed devices. But perhaps there are other operational reasons not to do so. Some explanation would be useful. I agree with Barry's DISCUSS points regarding 2.5 and section 3. The Valid-For option only applies to the Location-URI? Perhaps it should be named "Location-Valid-For" or "Location-URI-Valid-For". I can certainly imagine other expiring values appearing in DHCP messages that are not tied to the lease time. Seems like a poor choice for a name that is specific. So, why is the Valid-For not simply included in the Location URI Option? Just put the 4 octets before the URI and the length is always length of URI + 4. Wouldn't that be easier? |
2013-02-05
|
18 | Pete Resnick | [Ballot Position Update] New position, Discuss, has been recorded for Pete Resnick |
2013-02-05
|
18 | Sean Turner | [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss |
2013-02-05
|
18 | James Polk | New version available: draft-ietf-geopriv-dhcp-lbyr-uri-option-18.txt |
2013-02-04
|
17 | Benoît Claise | [Ballot comment] This document is scrutinized by Barry, Sean, Martin, and Stephen. I has enough attention, and I trust those ADs will do the right … [Ballot comment] This document is scrutinized by Barry, Sean, Martin, and Stephen. I has enough attention, and I trust those ADs will do the right thing. |
2013-02-04
|
17 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2013-02-04
|
17 | Martin Stiemerling | [Ballot discuss] I have no general objections to this draft, but multiple points to be discussed. However, most of my DISCUSS worthy issues are already … [Ballot discuss] 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. |
2013-02-04
|
17 | Martin Stiemerling | [Ballot comment] Here are a few points for your consideration: Section 7., paragraph 1: > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL … [Ballot comment] 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 ', 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. |
2013-02-04
|
17 | Martin Stiemerling | [Ballot Position Update] New position, Discuss, has been recorded for Martin Stiemerling |
2013-02-03
|
17 | Stephen Farrell | [Ballot discuss] 1) I suspect there's an unfounded assumption built in to this draft (and plenty of other IETF work) that runs counter to good … [Ballot discuss] 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. |
2013-02-03
|
17 | Stephen Farrell | [Ballot comment] - I agree with Barry's first discuss point - intro: Is the DHCP client really the Geopriv target? I think that'd be better … [Ballot comment] - 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. |
2013-02-03
|
17 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2013-02-03
|
17 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica |
2013-02-02
|
17 | Barry Leiba | [Ballot discuss] Alert: This is a long DISCUSS, but don't be daunted; remember that DISCUSS means that I need to discuss stuff with the authors … [Ballot discuss] Alert: This is a long DISCUSS, but don't be daunted; remember that DISCUSS means that I need to discuss stuff with the authors (et al). The first item is fundamental, but is likely to be sorted out by whacking me over the head with some history and explanation. I have already talked with Robert about it, and I think I might understand. I'd like to hear what James can tell me about it. Something from Section 3 first: Location URIs MUST NOT reveal identity information of the user of the device, since DHCP is a cleartext delivery protocol. This brings up a fundamental issue I have with this document: DHCP seems a particularly bad protocol to use for exchanging this sort of information, and you already have HTTP for the purpose. I don't understand the need for retrieving these URIs over DHCP -- I don't understand the need at all, and I certainly don't understand why what need you might have would override the problems associated with it, compared with using HTTP. Please explain this. -- Section 4 -- The IANA Considerations here seem entirely inadequate for figuring out what you're asking IANA to do where. I see that Pearl complained about this during Last Call, 7 months and two draft versions ago, and that it's been changed... but the changes do not address Pearl's questions. In particular, the four subsections say that the document registers four values, but it doesn't make it clear in what registries those values are registered in. Please update the document to be clear about that (check http://www.iana.org/protocols and use the correct registry name(s)). Section 3.2 says this: 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. I don't see that this document creates a registry for these; Section 3.3 merely lists, statically, five acceptable URI schemes. Do you still intend to have a registry for them? ----------------- The rest of these points are really editorial, but are points where I think the document lacks clarity sufficiently that I think they're likely to lead to confused implementations, especially by people who aren't deeply into this stuff: -- Section 2.5 -- 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. I think this isn't specified quite right: if a client gets a Valid-For option without any Location URI option, it's supposed to ignore it, according to the 5th unnumbered bullet. But this says it has to use it to overwrite the existing value. o Clients MUST NOT trigger an automatic DHCP refresh on expiry of the Valid-For timer; rather, they SHOULD follow normal DHCP mechanics. SHOULD? Really? Why is this not MUST? What else might they do, and why? -- Section 3 -- Caution SHOULD always be used involving the creation of large Options, meaning that this Option MAY need to be in its own INFORM, OPTION or ACK message. 1. What does that SHOULD really mean, and how can an implementor understand and fully weigh the implications of not doing this? 2. The "MAY" is completely wrong here, as a 2119 key word. This is not describing optional behaviour, but, rather, is talking about a situation in which something specific might have to be done. Per [RFC2131], subsequent LocationURI Options, which are non-concatenated, overwrite the previous value. I'm really having trouble following this. First, I don't know what it is in 2131 you're citing. Can you give a more specific citation ("[RFC2131], Section 6.6.6") to help? And your non-restrictive clause is throwing me: why, specifically, are they non-concatenated? Or do you mean for it to be restrictive ("subsequent LocationURI Options that are not concatenated overwrite the previous value.") ? -- Section 3.3 -- Responses to requests for URIs with other schemes ("sip", "sips", "http", and "https") MUST have MIME type 'application/pidf+xml'. I don't know what it means for a DHCP response to have a MIME type (which, by the way, should be changed to "media type"). Please explain. In fact, this whole section confuses me, as it seems to refer to things that have nothing to do with getting URIs through DCHP. This looks like stuff that's appropriate for HTTP. Can you help me understand? Maybe I'm just missing it. |
2013-02-02
|
17 | Barry Leiba | [Ballot comment] -- Section 1 -- This location URI points a Location Server [RFC5808] which has the geolocation of the client … [Ballot comment] -- Section 1 -- This location URI points a Location Server [RFC5808] which has the geolocation of the client (e.g., uploaded into a wiremap database when the client attached wall-jack, or by means of 802.11 geolocation mechanisms). Couple of typos in here; the second one makes it unclear: 1. "points TO a Location Server" 2. I can't figure out how to parse "uploaded into a wiremap database when the client attached wall-jack", and I don't know what you mean to say. -- Section 2.5 -- o Implementation of the Location URI Option is mandatory on the DHCP server and client, per this specification. o Implementation of the Valid-For Option is OPTIONAL on the DHCP server and client, per this specification. Is there a reason these are not parallel in their use of 2119 keywords? Maybe change "mandatory" in the first bullet to "REQUIRED"? (And, by the way, I find the "per this specification" to be a bit silly, and unnecessary.) o The Location URI Option MUST be sent from a server, and received by a client with or without an accompanying Valid-For Option. o The Valid-For Option MUST NOT be sent from a server, and received by a client, without an accompanying Location URI Option. I don't see how you can write 2119 language about what gets received, only about what gets sent. Is there a reason not to remove ", and received by a client," from both of these? o Servers MUST assume that clients will overwrite any existing, previously sent values of Location URI Option and/or Valid-For Option. "MUST assume" sounds really odd, and, anyway, this item is entirely unnecessary, as it's covered by the next one, which is properly formed. -- 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]. I find the first sentence awkward, and it took me a few passes to get the right sense of it. Further, again, what is the protocol problem that this is meant to address? The second sentence already says that we can deal with longer messages. I suggest getting rid of the 2119 language, and putting it this way: NEW DHCP messages are limited in size, and long URIs will require the use of multiple messages and concatenation [RFC3396]. It is, therefore, best to limit the total length of a URI, including any parameters, to 220 bytes. (I picked 220 so it will fit into a v6 message; adjust this text as appropriate. If you really think you need to put in a SHOULD or RECOMMENDED, it'll go in the second sentence of my suggestion.) -- Section 3.2 -- o URIs received via this Option MUST NOT be automatically sent to a general-browser to connect to a web page, because they could have harmful scripts. What if I have a browser that's set up to defend against harmful scripts? What if I have a browser that doesn't run scripts automatically? This seems a perfect place to have a SHOULD NOT, and simply to explain the threat. o This Option MUST NOT contain "data:" URLs, because they could contain harmful scripts. And I'm puzzled about this: http and data URIs can both get me to harmful scripts when they're dereferenced. The former are allowed and the latter are forbidden. Why is that? |
2013-02-02
|
17 | Barry Leiba | [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba |
2013-02-01
|
17 | Sean Turner | [Ballot discuss] 1) s2.5 Valid-For: I see where servers are configured to return values and it isn't understood it's ignored, but what's the default client … [Ballot discuss] 1) s2.5 Valid-For: I see where servers are configured to return values and it isn't understood it's ignored, but what's the default client behavior for an unknown or missing Valid-For time? I.e., does it use it indefinitely or for an hour or local policy? There's something in s3 about local timers but I thought that was DHCP timers. 2) s5: Because this option can be used with both DHVPv4 and DHCPv6 you need to also point to 3315. Might I suggest the following (similar to text from RFC 6225): Where critical decisions might be based on the value of this location URI option, DHCP authentication as defined in "Authentication for DHCP Messages" [RFC3118] and "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" [RFC3315] SHOULD be used to protect the integrity of the DHCP options. and then also that it's not just 3118 it's also 3315 in the next paragraph. 3) s5: In the 3rd paragraph, is security meant to be confidentiality/privacy protection? I think what you're trying to say is: DHCP, initially, is a broadcast request (a client looking for a server), and a unicast response (answer from a server) type of protocol. There is no privacy protection for DHCP messages, an eavesdropper who can monitor the link between the DHCP server and requesting client can discover the Location URI. And then add the following maybe at the end of the section: Link-layer confidentiality and integrity protection may also be employed to reduce the risk of location disclosure and tampering. |
2013-02-01
|
17 | Sean Turner | [Ballot comment] s1: r/points a Location/points to a Location s1: r/within a domain).Scaling/within a domain). Scaling |
2013-02-01
|
17 | Sean Turner | [Ballot Position Update] New position, Discuss, has been recorded for Sean Turner |
2013-01-31
|
17 | Jean Mahoney | Request for Telechat review by GENART is assigned to Alexey Melnikov |
2013-01-31
|
17 | Jean Mahoney | Request for Telechat review by GENART is assigned to Alexey Melnikov |
2013-01-31
|
17 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Chris Lonvick |
2013-01-31
|
17 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Chris Lonvick |
2013-01-31
|
17 | Alissa Cooper | Annotation tag Doc Shepherd Follow-up Underway set. |
2013-01-31
|
17 | Alissa Cooper | Changed protocol writeup |
2013-01-30
|
17 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2013-01-29
|
17 | Stewart Bryant | [Ballot comment] There a couple of places where you use the work "deference" when I think you mean "dereference" |
2013-01-29
|
17 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2013-01-29
|
17 | Robert Sparks | State changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2013-01-29
|
17 | Robert Sparks | Placed on agenda for telechat - 2013-02-07 |
2013-01-29
|
17 | Robert Sparks | Ballot has been issued |
2013-01-29
|
17 | Robert Sparks | [Ballot Position Update] New position, Yes, has been recorded for Robert Sparks |
2013-01-29
|
17 | Robert Sparks | Created "Approve" ballot |
2013-01-28
|
17 | James Polk | New version available: draft-ietf-geopriv-dhcp-lbyr-uri-option-17.txt |
2013-01-27
|
16 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-01-27
|
16 | James Polk | New version available: draft-ietf-geopriv-dhcp-lbyr-uri-option-16.txt |
2012-07-19
|
15 | Robert Sparks | State changed to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead |
2012-07-13
|
15 | Samuel Weiler | Request for Early review by SECDIR Completed: Ready with Nits. Reviewer: Chris Lonvick. |
2012-06-28
|
15 | Samuel Weiler | Request for Early review by SECDIR is assigned to Chris Lonvick |
2012-06-28
|
15 | Samuel Weiler | Request for Early review by SECDIR is assigned to Chris Lonvick |
2012-06-19
|
15 | Alexey Melnikov | Request for Last Call review by GENART Completed. Reviewer: Alexey Melnikov. |
2012-06-19
|
15 | Pearl Liang | IANA has reviewed draft-ietf-geopriv-dhcp-lbyr-uri-option-15 and has the following comments: IANA has questions about the IANA Actions requested in this document. Upon approval of this document … IANA has reviewed draft-ietf-geopriv-dhcp-lbyr-uri-option-15 and has the following comments: IANA has questions about the IANA Actions requested in this document. Upon approval of this document there appear to be three actions requested of IANA. First, the document asks that: "IANA registers this IPv4 Option number XXX (to be assigned by IANA once this document becomes an RFC)." IANA believes that this request is actually for a DHCP Option Number as usually registered in the BOOTP Vendor Extensions and DHCP Options subregistry of the Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters registry located at: http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xml However, the authors provide no further information about how the value is to be registered (for instance, name data length, meaning, etc.). IANA Question -> could the authors provide a more robust and precise description of their first request for registration in the IANA Considerations Section of their document? Second, the document also asks that: "IANA registers this IPv6 Option-Code XXX (to be assigned by IANA once this document becomes an RFC). IANA believes this request is actually for a DHCPv6 Option Code as usually registered in the DHCP Option Codes subregistry of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) registry located at: www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml IANA Question -> could the authors provide a more robust and precise description of their second request for registration in the IANA Considerations Section of their document? Third, the authors request the creation of a new registry for acceptable location types. IANA Question -> What should the name of the registry be? Where should it be located? In an existing registry or in a brand new registry? IANA understands that the new registry would be managed through the Standards Track process. Initial values are provided for the new registry as follows: +------------+----------------------------------------+---------------+ | LuriType | Name | Reference | +------------+----------------------------------------+---------------+ | 1 | Location URI | [ RFC-to-be ] | | 2 | Valid-For | [ RFC-to-be ] | +------------+----------------------------------------+---------------+ IANA requires further clarity on all three actions requested by this document. * RFC XXXX is to be replaced with this document's RFC-Editor RFC number. Additions to this registry require a standards track RFC. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. |
2012-06-14
|
15 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2012-06-07
|
15 | Jean Mahoney | Request for Last Call review by GENART is assigned to Alexey Melnikov |
2012-06-07
|
15 | Jean Mahoney | Request for Last Call review by GENART is assigned to Alexey Melnikov |
2012-05-31
|
15 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Dynamic Host Configuration Protocol (DHCP) IPv4 … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI)) to Proposed Standard The IESG has received a request from the Geographic Location/Privacy WG (geopriv) to consider the following document: - 'Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-06-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document creates a Dynamic Host Configuration Protocol (DHCP) Option for transmitting a client's geolocation Uniform Resource Identifier (URI). This Location URI can then be dereferenced in a separate transaction by the client or sent to another entity and dereferenced to learn physically where the client is located. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-geopriv-dhcp-lbyr-uri-option/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-geopriv-dhcp-lbyr-uri-option/ballot/ No IPR declarations have been submitted directly on this I-D. |
2012-05-31
|
15 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2012-05-31
|
15 | Robert Sparks | Last call was requested |
2012-05-31
|
15 | Robert Sparks | Ballot approval text was generated |
2012-05-31
|
15 | Robert Sparks | State changed to Last Call Requested from AD Evaluation |
2012-05-31
|
15 | Robert Sparks | Last call announcement was generated |
2012-05-31
|
15 | Robert Sparks | Last call announcement was generated |
2012-05-31
|
15 | Robert Sparks | Changed protocol writeup |
2012-05-31
|
15 | James Polk | New version available: draft-ietf-geopriv-dhcp-lbyr-uri-option-15.txt |
2012-05-29
|
14 | Robert Sparks | State changed to AD Evaluation from AD Evaluation::Point Raised - writeup needed |
2012-05-29
|
14 | Robert Sparks | Ballot writeup was changed |
2012-05-29
|
14 | Robert Sparks | Ballot writeup was generated |
2012-05-29
|
14 | Robert Sparks | Shepherd Writeup by Alissa Cooper - (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is … Shepherd Writeup by Alissa Cooper - (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? The type of RFC being requested is Proposed Standard. This is the proper RFC type because this draft is defining a new DHCP option and DHCP is an Internet standards track protocol. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document creates a Dynamic Host Configuration Protocol (DHCP) Option for transmitting a Uniform Resource Identifier (URI) that points to a client's geolocation. The URI can be dereferenced in a separate transaction to obtain the client's geolocation. Working Group Summary This document represents the consensus of the GEOPRIV working group. The document went through several revisions in order to establish a clear understanding of the security model surrounding location URIs passed via DHCP, but WG participants are now satisfied with the description of the model provided in the document. Document Quality This document has been extensively reviewed by GEOPRIV participants and members of the DHC WG. The most recent round of DHC reviews resulted in changes to the document to ensure that the option specified here does not conflict with DHCP lease expiration behavior. Personnel Alissa Cooper is the document shepherd. Robert Sparks is the responsible area director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The shepherd conducted a thorough review of the document before submitting the -11 version for publication in April of 2011. Since then, the document has had further review from the DHC WG. The shepherd was involved in drafting changes to the document to satisfy the DHC reviewers and has reviewed the final changes to the document. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. The necessary DHC reviews have already taken place. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The shepherd has no specific technical concerns with this document to which to call attention. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. The author has confirmed that no disclosures need to be filed. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures have been filed against this document (although there was a message about IPR posted to IETF-Discussion on October 13, 2010). (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The GEOPRIV working group has discussed this document at length and reached consensus about its content. Disagreements within the group have been resolved. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) There have been no threatened appeals or expressions of extreme discontent against this document. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The copyright year needs to be updated to 2012. The reference to RFC 5808 should be changed to informative rather than normative. The references to RFC 3825 should be changed to refer to RFC 6225, which obsoleted RFC 3825 since this document was first publication requested. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal reviews are necessary for this document. The URI types were discussed at length during the early life of the document. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? There are no such references. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. There is one downward normative reference that is listed by mistake and should be changed to informative. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. Publication of this document will not change the status of any existing RFCs. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The shepherd has verified that the document's IANA consideration section exists and is consistent with the body of the document. The document makes three requests of IANA: a v4 option number, a v6 option code, and a registry of location types (LuriTypes). (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No proposed registries require Expert Review. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. No such sections exist. |
2012-05-15
|
14 | Robert Sparks | The writeup should be updated to reflect the extra review in DHC and the new template. |
2012-05-15
|
14 | Robert Sparks | State changed to AD Evaluation::Point Raised - writeup needed from AD Evaluation::External Party |
2012-03-12
|
14 | James Polk | New version available: draft-ietf-geopriv-dhcp-lbyr-uri-option-14.txt |
2012-03-10
|
13 | James Polk | New version available: draft-ietf-geopriv-dhcp-lbyr-uri-option-13.txt |
2011-10-12
|
12 | Robert Sparks | State changed to AD Evaluation::External Party from AD Evaluation::AD Followup. Tracking discussion with DHC |
2011-10-03
|
12 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2011-10-03
|
12 | (System) | New version available: draft-ietf-geopriv-dhcp-lbyr-uri-option-12.txt |
2011-05-31
|
12 | Robert Sparks | State changed to AD Evaluation::Revised ID Needed from Publication Requested. |
2011-05-31
|
12 | Cindy Morgan | Area acronym has been changed to rai from gen |
2011-04-13
|
12 | Amy Vezza | (1.a) The document shepherd for this document is Alissa Cooper. The document shepherd has personally reviewed the document and believes that this document is fit … (1.a) The document shepherd for this document is Alissa Cooper. The document shepherd has personally reviewed the document and believes that this document is fit for publication. (1.b) This document has been thoroughly reviewed by the GEOPRIV working group, as well as key members of the DHC working group. (1.c) There are no specific areas within this document that necessitate additional external review, but it may be helpful to get another DHC reviewer during LC. (1.d) The shepherd has no specific technical concerns with this document to which to call attention. It could benefit from an editorial review to ensure that the concepts are expressed in an understandable way to those outside the WG. No IPR disclosures have been filed against this document (although there was a message about IPR posted to IETF-Discussion on October 13, 2010). (1.e) The GEOPRIV working group has discussed this document at length and reached consensus about its content. Disagreements within the group have been resolved. (1.f) There have been no threatened appeals or expressions of extreme discontent against this document. (1.g) The shepherd has checked the document for ID nits. The document's Trust boilerplate needs to be updated to the most recent version, and it has a form feed error. Otherwise, the document meets the checklist criteria and has no need for any additional reviews. (1.h) The document's references are split into normative and informative sections. There are two references in the normative section, to RFC 4119 and RFC 5808, which should be in the informative section, and a reference in the informative section, to RFC 2616, which should be in the normative section. Once RFC 5808 is moved to the appropriate section there will be no downward references. (1.i) The shepherd has verified that the document's IANA consideration section exists and is consistent with the body of the document. The document makes four requests of IANA: a v4 option number, a v6 option code, a registry of acceptable URI types, and a registry for location types. (1.j) There are no instances of formal language in this document. (1.k) Announcement Writeup: Technical Summary: This document creates a Dynamic Host Configuration Protocol (DHCP) Option for transmitting a Uniform Resource Identifier (URI) that points to a client's geolocation. The URI can be dereferenced in a separate transaction to obtain the client's geolocation. Working Group Summary: This document represents the consensus of the GEOPRIV working group. The document went through several revisions in order to establish a clear understanding of the security model surrounding location URIs passed via DHCP, but WG participants are now satisfied with the description of the model provided in the document. Document Quality: This document has been extensively reviewed by GEOPRIV participants. |
2011-04-13
|
12 | Amy Vezza | Draft added in state Publication Requested |
2011-04-13
|
12 | Amy Vezza | [Note]: 'The document shepherd for this document is Alissa Cooper (acooper@cdt.org).' added |
2011-02-11
|
11 | (System) | New version available: draft-ietf-geopriv-dhcp-lbyr-uri-option-11.txt |
2011-02-11
|
10 | (System) | New version available: draft-ietf-geopriv-dhcp-lbyr-uri-option-10.txt |
2010-10-13
|
09 | (System) | New version available: draft-ietf-geopriv-dhcp-lbyr-uri-option-09.txt |
2010-07-28
|
08 | (System) | New version available: draft-ietf-geopriv-dhcp-lbyr-uri-option-08.txt |
2010-03-07
|
07 | (System) | New version available: draft-ietf-geopriv-dhcp-lbyr-uri-option-07.txt |
2009-09-15
|
06 | (System) | New version available: draft-ietf-geopriv-dhcp-lbyr-uri-option-06.txt |
2009-07-13
|
05 | (System) | New version available: draft-ietf-geopriv-dhcp-lbyr-uri-option-05.txt |
2009-03-09
|
04 | (System) | New version available: draft-ietf-geopriv-dhcp-lbyr-uri-option-04.txt |
2008-11-04
|
03 | (System) | New version available: draft-ietf-geopriv-dhcp-lbyr-uri-option-03.txt |
2008-06-16
|
02 | (System) | New version available: draft-ietf-geopriv-dhcp-lbyr-uri-option-02.txt |
2008-06-16
|
01 | (System) | New version available: draft-ietf-geopriv-dhcp-lbyr-uri-option-01.txt |
2008-02-25
|
00 | (System) | New version available: draft-ietf-geopriv-dhcp-lbyr-uri-option-00.txt |