Subject: [Geopriv] Fwd: New DHCP Location URI version submitted

From: "James M. Polk" <[email-masked]>
Date: Tue, 15 Sep 2009 16:18:11 -0500

Hannes

To be clear -- wrt the discussion on the interim call I said that

  [ID-GEO-POL] H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J.
            Polk, "Geolocation Policy: A Document Format for Expressing
            Privacy Preferences for Location Information", "work in
            progress", Feb 2009

was in the Normative References section of -06. It isn't.

It's in the Informative References section (meaning I didn't move it 
from where I had it in the -05 version).

I apologize.

I'll move this up to the Normative References section, and update the 
date (to July 09 from Feb 09).

James

>Date: Mon, 14 Sep 2009 20:37:15 -0500
>To: [email-masked]
>From: "James M. Polk" <[email-masked]>
>Subject: [Geopriv] New DHCP Location URI version submitted
>
>Geopriv
>
>         Title           : Dynamic Host Configuration Protocol 
> (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI)
>         Author(s)       : J. Polk
>         Filename        : draft-ietf-geopriv-dhcp-lbyr-uri-option-06.txt
>         Pages           : 13
>         Date            : 2009-09-14
>
>         This document creates a Dynamic Host Configuration Protocol (DHCP)
>         Option for transmitting a client's geolocation Uniform Resource
>         Identifier (URI) of a client, which can be dereferenced in a
>         separate transaction by the client or an entity the client sends
>         this URI to.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-lbyr-uri-option-06.txt
>
>I am including a detailed response to Hannes' PDF below, which had 
>23 "comments" throughout the PDF, as well as a LOT of little 
>edits.  I incorporated most of the edits, though I didn't agree with 
>every one of them.
>
>Below is my response to each of the "comments" made within that 
>review. I kept Hannes' numbering in case anyone wants to track them. 
>He sent this PDF to the list on July 20th, so I won't include that 
>attachment here.
>
>Comments to this set of responses is encouraged.
>
>Comment[TH1]: This is not true. First, it depends on the URI scheme 
>what specification has to be used. Second, [ID-SIP-LOC] does not 
>describe how dereferencing works. It only describes how to convey 
>the reference (or a value).
>
>       - see Section 4.5 of conveyance for this. The mechanism is 
> the same for location-by-reference (where the LR needs to request 
> the Target's location from an LS), and the LR just asking for a 
> Target's location without receiving the location URI in the 
> preceding transaction (i.e., not via conveyance) -- as long as SIP 
> is used, that is. There's nothing in the SUBSCRIBE that's different 
> (i.e., the same SIP headers are used). The same is true for the 
> NOTIFY.  The only possible difference is if the SUBSCRIBE includes 
> some presence filters that ask for a list of fields to be in the 
> NOTIFY, or if location tracking is requested (i.e., periodic or 
> triggered NOTIFYs).  These additional indications are not necessary 
> for an LR to receive a Target's PIDF-LO -- they just change what 
> can be in the PIDF-LO and how often the LR receives the PIDF-LO (if 
> that part of the subscription is granted).
>
>Comment[TH2]: The term "dereferencer" does not exist.
>
>       - changed to "...dereferencing entity..."
>
>Comment[TH3]: To what does the "defined in" refer to?
>
>       - whether or not the dereferencing entity has permission to 
> attain the Target's location.
>
>Comment[TH4]: This is a use case for the SIP Location Conveyance 
>document. Do you think it fits in here?
>
>       - I agree, so I removed this in -06
>
>Comment[TH5]: Why would you want to hand out the same reference to 
>different entities?
>
>       - Why would all Targets (i.e., phones, ATAs, PDAs, TIVOs, 
> iPods, etc) within the same residence need separate location URIs? 
> Most will never be outside of the same residence.  Take this out to 
> a SP level of scaling of (from a few to many (dozens?) URIs per 
> household vs. 1 URI per household). What's the impact on the 
> backend systems?  I believe the same is true for all the Cisco 
> phones within the same building at any campus throughout the 
> company. They won't ever move without getting a new DHCPDISCOVER 
> download (meaning they've had to reboot - because nearly all are 
> PoE-based now). This applies to a lot of cases, not just the 
> outlier cases.  Mobile environments are different, but most devices 
> aren't mobile, so the option is stated here for either.
>
>Comment[TH6]: As mentioned by someone in the group this term does 
>not exist in our vocabulary.
>
>      - This was pointed out at the mike by Martin, and is actually 
> not true at all. RFC 3693, section 5.1 (titled " Location 
> Information and Sighting") defines and describes the act of 
> "Sighting".  Here is the text:
>
>   "Within any given location-based transaction, the INITIAL
>    determination of location (and thus the initial creation of Location
>    Information) is termed a Sighting:
>
>       Sighting:
>          The initial determination of location based on non-public
>          information (as discussed in the definition of Location
>          Information), and the initial creation of Location
>          Information."
>
>
>       To call out something as a Sighter fits the definition, and 
> isn't out of place - regardless of how it has been portrayed as 
> inappropriate at any microphone discussion.
>
>Comment[TH7]: I am not sure what is configured here?
>
>       - residential gateways are often DHCP servers to all home 
> clients, where the gateway appears to the operator as a single 
> end-system. This is analogous to that - where the gateway hands out 
> the same location URI to each client that was given to it by the 
> operator.  In WiMAX, this usage can be expanded to include 
> connectivity such as MiFi scenarios, for example.
>
>Comment[TH8]: A right term might be "Location Recipient"
>
>       - fair point, but I'm going to go with "dereference request" 
> instead of just dereference or LR, because at the beginning it's 
> the request that's being challenged, not the potential LR (given 
> that it hasn't received any location yet). Here's the new first 
> part of the sentence (changing the word "challenges" too):
>
>       "How an LS responds to a dereference request can vary..."
>
>Comment[TH9]: We don't provide this information in the Geolocation policy.
>
>       - right, but that doesn't mean it can't exist outside of the 
> Geolocation Policy ID. It could be a case of the operator 
> configuring all this without a target's involvement, or it could be 
> a judge that sets the rules. In other words, this would be done 
> outside of any protocol transactions.  Also note, I don't reference 
> [ID-GEO-POL], which is the Geolocation Policy ID that is reference 
> elsewhere in the ID.
>
>Comment[TH10]: Location Recipient
>
>       - thanks, changed
>
>Comment[TH11]: Not true since you will not arrive at an 
>interoperable implementation.
>
>       - The comment you made to this last sentence is focused on 
> DHCP, which will have zero to do with however this could be done in 
> IP, therefore this sentence is written appropriately.
>
>Comment[TH12]: Why don't you call it LbyR?
>
>       - There is disagreement what the difference is between an 
> LbyR and a Location URI, therefore I've scrubbed the ID of "LbyR" 
> (except for the filename (that won't exist whenever this doc becomes an RFC).
>
>Comment[TH13]: Wouldn't it start with sending the URI?
>
>       - no, because the DHCP Server is not tracking the timer for 
> each of its clients. It's the clients that are individually keeping 
> track of the timers, and there is no way for the clients to know 
> how long it took to receive the message from the Server. This is a 
> pretty small difference either way we look at this.
>
>Comment[TH14]: What is the lifetime of the location URI if this 
>parameter is not included.
>
>       - the lifetime of the IP address lease, which is a little 
> vague in the previous paragraph, so I firmed up this and the next 2 
> paragraphs to be clear on the point.
>
>Comment[TH15]: To what does this correspond in 
>http://bgp.potaroo.net/ietf/idref/rfc5226/?
>
>       - from the bottom of Section 3.1 of RFC 5226, there is this:
>
>   "In many cases, some review of prospective allocations is
>    appropriate, and the question becomes who should perform the review
>    and what is the purpose of the review."
>
>       This gets into that "some review is often desirable". Couple 
> the previous paragraph with the next paragraph:
>
>   "One way to ensure community review of prospective assignments is to
>    have the requester submit a document for publication as an RFC.
>    Such an action helps ensure that the specification is publicly and
>    permanently available, and it allows some review of the
>    specification prior to publication and assignment of the requested
>    code points. This is the preferred way of ensuring review, and is
>    particularly important if any potential interoperability issues can
>    arise."
>
>       And you should see that stating an RFC is necessary to extend 
> this doc just fine with RFC 5226.
>
>Comment[TH16]: How does this SHOULD fit to the MUST NOT from above.
>
>       - it doesn't. I corrected it.
>
>Comment[TH17]: Not sure what this means.
>
>       - removed the paragraph
>
>Comment[TH18]: This paragraph does not fit to the previous and to 
>the next one. Additionally, it is not clear how these things would 
>work in such a setting.
>
>       - I agree, therefore I've removed the paragraph
>
>Comment[TH19]: I believe that your idea of focusing on the 
>authorization model does not work.
>
>       - you said that you were ok with my picking the authorization 
> model in the email you sent me this PDF, now you say the 
> authorization model doesn't work - and don't tell me why. I cannot 
> work from this comment.  This document doesn't assume possession of 
> the Location URI equals authorization to see a target's location. 
> How else can I say that?  The next bullet (after this comment) 
> pretty clearly says "this is for authorization model deployments" - 
> but this is merely an assumption (from the section title), and can 
> be used in the possession model).
>
>Comment[TH20]: I am not sure why you need to use 2 terms, namely 
>rulemaker and ruleholder.
>
>       - fixed this, I got caught up in the WG also using Rulemaker, 
> when in fact that term is not defined in RFC3693 (which only 
> defines "Ruleholder"). I have replaced all references to the 
> rulemaker with Ruleholder.
>
>Comment[TH21]: Delete this sentence. It does not make a sense.
>
>       - done
>
>Comment[TH22]: I am not sure what this means.
>
>       - I took this out too
>
>Comment[TH23]: Why do you repeat it again?
>
>       - removed paragraph
>
>Comment[TH24]: Don't capture debates in this document. I don't think 
>it is good writing style.
>
>       - part of the intent here is to prompt questions during 
> review, as this discussion has never been resolved that I know of, 
> regardless how long we debated the topic.
>
>       I'll remove the paragraph anyway...
>
>James
>
>_______________________________________________
>Geopriv mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/geopriv