Thanks for the update.
One important aspect upfront: During the virtual interim meeting you
said that Common Policy and Geolocation Policy are now normative
references. However, when I looked at
http://www.ietf.org/id/draft-ietf-geopriv-dhcp-lbyr-uri-option-06.txt
and I could not find Common Policy reference at all, nor the geolocation
draft as a normative reference. Finally, I guess you have to reference
XCAP as well since you need to have a way to "transport" (or upload) the
policies.
Please find my comments below.
>-----Original Message-----
>From: geopriv-bounces@ietf.org
>[mailto:geopriv-bounces@ietf.org] On Behalf Of ext James M. Polk
>Sent: 15 September, 2009 04:37
>To: geopriv@ietf.org
>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-lby
>r-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).
SIP Location Conveyance does not exactly add a lot of new information to
the dererefence of SIP URIs other than what is know already from other
specs. Hence, it is not really relevant to this document.
>
>Comment[TH2]: The term "dereferencer" does not exist.
>
> - changed to "...dereferencing entity..."
Good.
>
>Comment[TH3]: To what does the "defined in" refer to?
>
> - whether or not the dereferencing entity has
>permission to attain the Target's location.
I think you better expand the description a bit or remove the reference.
It is hard to capture the idea of the sentence.
>
>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
OK.
>
>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.
Understood.
>
>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.
Sighter does not exist as a role in the architecture. You could say that
the LIS does sighting, if you think that this will give you a lot of
additional value when people have to lookup that term in RFC 3693.
>
>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.
>
The sentence sounds somewhat strange if you read it:
"
The location URI Option can be configured as a
client if there is a router, such as a residential home gateway,
with the ability to communicate to downstream endpoints as a server.
"
You can configure a DHCP server to do something but the Location URI is
just a string and that string gets dumped into another container in
DHCP.
>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..."
>
The LS (which is actually a LIS, btw) will run a security protocol to
authenticate the LR to then figure out whether the authorization
policies match to the identity of the LR and so on. Changing the
sentence in the way you suggested is good.
>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.
That's correct. It could be a proprietary mechanism. Since you make
references to the geolocation policy document it might be good to say
that this functionality goes beyond of what is provided today. Just a
thought.
>
>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.
There are things that are outside the scope of DHCP but still relevant
for this document. The most recent example is the authorization policy
mechanism.
So, making this generic statement is not correct.
>
>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).
I have not heard about this disagreement.
>
>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.
Then, the server who maintains these references is assumed to store them
for the indicated period of time. Right?
>
>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.
Thanks.
>
>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.
To make the life of IANA easier (and those who read the document) I
would suggest to just use one of the terms from RFC 5226.
So, maybe you want "Expert Review"?
>
>Comment[TH16]: How does this SHOULD fit to the MUST NOT from above.
>
> - it doesn't. I corrected it.
OK.
>
>Comment[TH17]: Not sure what this means.
>
> - removed the paragraph
OK.
>
>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
Ok.
>
>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).
We discussed this comment during the virtual interim meeting.
>
>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.
Ok
>
>Comment[TH21]: Delete this sentence. It does not make a sense.
>
> - done
Ok
>
>Comment[TH22]: I am not sure what this means.
>
> - I took this out too
Ok
>
>Comment[TH23]: Why do you repeat it again?
>
> - removed paragraph
Ok
>
>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...
Ok
Ciao
Hannes
>
>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
