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: geopriv@ietf.org
>From: "James M. Polk" <jmpolk@cisco.com>
>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
>Geopriv@ietf.org
>https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
