Subject: [Geopriv] New DHCP Location URI version submitted

From: "James M. Polk" <[email-masked]>
Date: Mon, 14 Sep 2009 20:37:15 -0500

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

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 18 Sep 2009 10:12:29 +0300

Hi James, 

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: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext James M. Polk
>Sent: 15 September, 2009 04:37
>To: [email-masked]
>Subject: [Geopriv] New DHCP Location URI version submitted
>
>Geopriv
>
>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.
>
>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 
>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. 

>       - changed to "...dereferencing entity..."

Good. 

>       - 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?
>

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:
>
>       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.

>       - 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. 

>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):
>

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. 

>       - 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[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. 

>       - 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. 

>       - 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. 

>       This gets into that "some review is often desirable". 
>Couple the previous paragraph with the next paragraph:
>
>       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"? 

>       - it doesn't. I corrected it.

OK. 

>Comment[TH17]: Not sure what this means.

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.
>

Ok. 

>       - 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.

Ok 

>Comment[TH22]: I am not sure what this means.

Ok 

>Comment[TH23]: Why do you repeat it again?

Ok 

>
>Comment[TH24]: Don't capture debates in this document. I don't 
>think it is good writing style.
>
>review, as this discussion has never been resolved that I know 
>of, regardless how long we debated the topic.
>

Ok 

Ciao
Hannes

>
>James
>
>_______________________________________________
>Geopriv mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/geopriv
>

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 18 Sep 2009 18:25:36 -0500

>Thanks for the update.

thanks for the feedback

>references.

I only said Geolocation Policy was referenced, and admitted in a note 
just after the call that I said this was Normative in -06, and 
intended to move this up to Normative (but didn't remember to do 
this), and in -06 it remained in the Informative references 
section.  I know why I put it there in -05, because that doc hadn't 
progressed very much within the IESG (for a long time with them), and 
I didn't want this URI doc to be bound on waiting for the Geolocation 
Policy to become an RFC.

I've already started an -07 of this URI doc, and I've already moved 
Geolocation Policy to the Normative section. That said - I do not 
have RFC 4745 in the references currently. Do you believe Common 
Policy and Geolocation Policy should be referenced within the same 
bullet of text (i.e., Section 3.1), or somewhere else?

>However, when I looked at

Geolocation Policy doesn't have a transport/upload mechanism. Do you 
really want this DHCP URI document to set the example of how 
Geolocation Policies get uploaded for all future Geopriv 
docs?  Doesn't that mean all future IDs/RFCs that reference 
Geolocation Policy will have to Normatively reference this DHCP URI 
doc because it was the *one* doc to specify that XCAP is to be used 
to upload/transport policies?

I thought you and I talked about that and agreed to add that (i.e., 
XCAP) into the Geolocation Policy doc. Am I wrong here?  This seems 
to me to be the (waaay) obvious way to go, thereby covering all 
Geopriv docs that require uploading policies to a LS.

>Please find my comments below.

comments back at you...

I don't think you and I are that far apart any longer on this doc. I 
do have a couple of questions below and ask for your opinion on which 
direction to go on some other points.

James

--Original Message-----
>specs. Hence, it is not really relevant to this document.

It is not blazing a new trail with whatt be covered within 
Conveyance, because you and I both know someone will ask "gee, how 
does an LR get location when it was only sent a location URI?"

Because I was asked that several times before this section was 
writt(example) en ieyce, I had to put it into the doc. Conveyanceing 
to resist removing it now, among the reasons is that it does no harm there.

>It is hard to capture the idea of the sentence.

I'll work on it

> >different, but most devices aren't mobile, so the option is

cool - I think this one was important to understand.

>additional value when people have to lookup that term in RFC 3693.

Personally, this term has clear meaning to me. I've always said - 
over the years - that I didn't understand why others didn't 
understand the term.  When 3693 was being written, this term was used 
frequently, a lot by Jorge (the editor of 3693), so it was an 
integral part of Geopriv's vernacular.

I'll work on this point...

>just a string and that string gets dumped into another container in

I'll rework the above sentence to make this point clearer, ok?

>that this functionality goes beyond of what is provided today. Just a

interesting.  Do you want me to open up that possibility ("...that 
this functionality goes beyond of what is provided today")?

>So, making this generic statement is not correct.

but I don't understand how this will become non-interoperable?

>I have not heard about this disagreement.

It was made by Martin - and he was adamant about it, seeming that I 
was clueless for not knowing this basic fact (going so far as to say 
I basically didn't deserve to talk about location at all, so why was 
I bothering to continue writing anything at the IETF about it).  Like 
I told him, I didn't get that memo, nor did I see the discussion about it.

I still don't understand the difference, but I didn't forget his 
berating of me (oh, how I love being attacked like that -- not!) - so 
I'm on a mission to never use the acronym LbyR again (after this 
time, or course) because I'm obviously clueless about what it means.

>for the indicated period of time. Right?

interesting... I'd have to say yes to this then.  I guess that isn't 
covered at all, and should be.

Given that DHCP responses aren't delayed that long in transit (from 
server to client), how long would you think a default time to retain 
the URI on the server should be (beyond server determined 'valid-for' value)?

Along those lines, should I add anything about keeping a URI for a 
specific client's MAC address? This would be something like my iPhone 
(connecting to my home WLAN network) always giving out the same 
location URI (when I am there) even though the 'valid-for' times out 
when periodically when I'm on trips?

This doesn't say anything about the location URI returning my PIDF-LO 
all the time (i.e., even when I'm not at home).  Is this something 
that ought to be addressed one way or the other?

>So, maybe you want "Expert Review"?

If I'm to choose one, I'd like to go the other way, and choose 
publish an RFC, because this should mean that the Geopriv WG (if 
still active) will get a chance to read the proposal, instead of one 
day looking at IANA and discovering things in IANA that either we 
didn't know about, or that don't make sense, or are conflicting with 
a new proposal, or are just wrong.

While Expert Review sounds good, sometimes the review isn't the best. 
Having an RFC means the community has a chance to read a proposal for 
new IANA registrations (though I'll admit we all have to pay 
attention for any LCs on this).

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 20 Sep 2009 19:07:15 -0500

Hi James,

Regarding the XCAP reference...

As Hannes has been saying, if you choose to use the access control or authorization policy model for location by reference, you need more than what this document is providing.

I can imagine that one way this works is:

 1. You acquire a location URI using DHCP.
 2. You establish authorization rules that the LS applies in relation to this location URI.
 3. You convey that location URI to potential location recipients.

I think that we are almost there one 1.  And 3.  There are mechanisms that exist for 2.  That's where XCAP comes in.  However, you need a way to tie these together.  You can't just say "use XCAP".  You need to describe which XCAP profile to use, which base URI to use.

Without that additional information, this can't be deployed.  It's an academic exercise only.

Once that issue is resolved, I think that we're a lot closer.  I do have some potential concerns,  however.

_Different URIs - implementation_

You state that each individual client receives a different URI.  This is necessary for your selected model and I'm glad that you've considered the residential case.

I am interested in how you imagine that this might be implemented in the residential case.  Do devices within a residence rely on the residential gateway to provide the URI?  If different URIs are required, how does the gateway mint these URIs or does it acquire them from some sort of upstream service?

--Martin
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 21 Sep 2009 10:30:34 +0300

Hi James, 

>I only said Geolocation Policy was referenced, and admitted in 
>a note just after the call that I said this was Normative in 
>-06, and intended to move this up to Normative (but didn't 
>remember to do this), and in -06 it remained in the 
>Informative references section.  I know why I put it there in 
>-05, because that doc hadn't progressed very much within the 
>IESG (for a long time with them), and I didn't want this URI 
>doc to be bound on waiting for the Geolocation Policy to become an RFC.

Good point; I have sent a separate mail about the status to the list. 
>
>I've already started an -07 of this URI doc, and I've already 
>moved Geolocation Policy to the Normative section. That said - 
>I do not have RFC 4745 in the references currently. Do you 
>believe Common Policy and Geolocation Policy should be 
>referenced within the same bullet of text (i.e., Section 3.1), 
>or somewhere else?

I would reference it in the same section. 

>>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.
>
>Geolocation Policy doesn't have a transport/upload mechanism. 

Correct. 

>Do you really want this DHCP URI document to set the example 
>of how Geolocation Policies get uploaded for all future 
>Geopriv docs?  Doesn't that mean all future IDs/RFCs that 
>reference Geolocation Policy will have to Normatively 
>reference this DHCP URI doc because it was the *one* doc to 
>specify that XCAP is to be used to upload/transport policies?

But if you don't specify a mechanism for how to get the policies to the
LIS then you cannot accomplish interoperability either. 

>XCAP) into the Geolocation Policy doc. Am I wrong here?  This 
>seems to me to be the (waaay) obvious way to go, thereby 
>covering all Geopriv docs that require uploading policies to a LS.

http://tools.ietf.org/html/draft-ietf-geopriv-policy-21#section-10 only
defines the technical content to allow XCAP to be used to upload these
policies (btw, we don't have the same for Common Policy...) but the
document format itself can utilize a number of different transports. 

Ciao
Hannes

>I don't think you and I are that far apart any longer on this 
>doc. I do have a couple of questions below and ask for your 
>opinion on which direction to go on some other points.
>
>James
>
>--Original Message-----
>> >       Filename        : 
>draft-ietf-geopriv-dhcp-lbyr-uri-option-06.txt
>> >       Pages           : 13
>> >       Date            : 2009-09-14
>> >
>> >incorporated most of the edits, though I didn't agree with 
>every one 
>> >of them.
>> >
>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.
>
>Conveyance, because you and I both know someone will ask "gee, 
>how does an LR get location when it was only sent a location URI?"
>
>writt(example) en ieyce, I had to put it into the doc. 
>Conveyanceing to resist removing it now, among the reasons is 
>that it does no harm there.
>
>
>
>> >
>> >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:
>> >
>>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.
>
>Personally, this term has clear meaning to me. I've always 
>said - over the years - that I didn't understand why others 
>didn't understand the term.  When 3693 was being written, this 
>term was used frequently, a lot by Jorge (the editor of 3693), 
>so it was an integral part of Geopriv's vernacular.
>
>>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.
>>"
>>
>it's the 
>> >which is the Geolocation Policy ID that is reference 
>elsewhere in the 
>> >ID.
>>
>interesting.  Do you want me to open up that possibility 
>("...that this functionality goes beyond of what is provided today")?
>
>
>> >