Subject: [Geopriv] Submitted rev of DHCP Option for LbyR

From: "James M. Polk" <[email-masked]>
Date: Mon, 03 Nov 2008 19:27:39 -0600

I've submitted a new version of
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-lbyr-uri-option-03.txt
for review and comments.

Hannes - I've addressed what I believe is your final comment wrt 
mentioning that dereferencing of a LbyR is done according to policy rules of
http://tools.ietf.org/wg/geopriv/draft-ietf-geopriv-policy/

This also gives much more of an architectural view to readers that 
James believes this ID is lacking.

James W. - I added in the doc that LbyRs can be unique, based on 
local policy, but I did not make it mandatory since I don't believe 
there was a conclusion of your discussion with Ted in which Ted took 
the stance that unique URIs are necessary if they represent the same 
location (say for all endpoints off an dot11 AP).

Your contention that they need to be unique because they move, there 
might be location mistakes appears to be addressed by the fact that 
movement off of an AP will cause another DHCP DISCOVERY or REQUEST, 
meaning that endpoint's URI will change to the one that is assigned 
to that new AP.

This does not seem overbearing or a waste of BW if done as few times 
this will occur.

Cellular uses of this will not be popular, and anything wired will 
always get the same stationary LbyR, so the point is mute in this scenarios.

With that, I believe I have addressed the last of the open issues wrt 
this ID, and therefore request publication, Robert.

James

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

---

From: Richard Barnes <[email-masked]>
Date: Tue, 04 Nov 2008 09:58:25 -0500

James,

Thanks for continuing to work on this draft.  I haven't read the new 
version carefully yet, but I have one question based on your email:

> meaning that endpoint's URI will change to the one that is assigned to 
> that new AP.

It seems like there's still uncertainty in the case where the client 
moves from an AP that supports location to one that doesn't.  I can see 
there being implementations that happily cache the URI and keep using it.

Would it be appropriate to add some text to the following effect: "A 
client MUST store the URI delivered in the most recent DHCP message it 
has received.  In particular, if the client receives a DHCP message that 
does not contain this Option, then it MUST remove any URIs it has 
previously received."

--Richard

---

From: "Roger Marshall" <[email-masked]>
Date: Tue, 4 Nov 2008 14:49:50 -0800

Robert:

This new version endeavours to incorporate all of the open issues
brought up on the list, specifically from Martin Thompson and James
Polk's review and comments dated 7/09/08 (as documented within the end
of the draft).  As such, I would like to make a request to you, that you
would recommend it for publication.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-lbyr-requirements
-04.txt

Sincerely,
Roger Marshall.

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Roger Marshall" <[email-masked]>
Date: Wed, 5 Nov 2008 14:05:45 -0800

A short comment here, and self-inflicted...  I offer an apology to
Martin Thomson for getting his name wrong in this new version of the
draft. (doh!) I will correct the references as "Thomson" and repost as
-05 after 11/17/08. 

-roger marshall. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Roger Marshall
> Sent: Tuesday, November 04, 2008 2:50 PM
> To: Robert Sparks; GEOPRIV
> Subject: [Geopriv] Submitted rev -04 of -LbyR-requirements
> 
> Robert:
> 
> This new version endeavours to incorporate all of the open 
> issues brought up on the list, specifically from Martin 
> Thompson and James Polk's review and comments dated 7/09/08 
> (as documented within the end of the draft).  As such, I 
> would like to make a request to you, that you would recommend 
> it for publication.
> 
> CONFIDENTIALITY NOTICE: The information contained in this 
> message may be privileged and/or confidential. If you are not 
> the intended recipient, or responsible for delivering this 
> message to the intended recipient, any review, forwarding, 
> dissemination, distribution or copying of this communication 
> or any attachment(s) is strictly prohibited. If you have 
> received this message in error, please notify the sender 
> immediately, and delete it and all attachments from your 
> computer and network.

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 05 Nov 2008 17:08:10 -0600

At 08:58 AM 11/4/2008, Richard Barnes wrote:
>>Your contention that they need to be unique because they move, 
>>there might be location mistakes appears to be addressed by the 
>>fact that movement off of an AP will cause another DHCP DISCOVERY 
>>or REQUEST, meaning that endpoint's URI will change to the one that 
>>is assigned to that new AP.
>
>moves from an AP that supports location to one that doesn't.

this is the first time anyone has brought that point up, that I recall.

I agree this scenario currently isn't covered, and probably should 
be. Thanks for uncovering it.

Normally when AP#1 supports location, a user agent receives its LbyR 
from the AP, which has identified its location based on the RAIO port 
its connected to. If this user agent moves to another AP(#2), the 
lower layer (i.e., radio attachment) detects this change, and the 
user agent acquires a new LbyR (because it is now within the radius 
of the second AP.

What to do about a scenario in which AP#2 (from the above example) 
doesn't understand location.  Ultimately, location isn't given out by 
the AP, which doesn't have logic in it to support anything Geopriv 
has (or likely will) define - given that we don't define what dot11 
devices do, that's IEEE's area of expertise.

I guess there are a couple of options in this case,

#1 - mandate that if the lower layer of a user agent detects this AP 
change, and doesn't receive a new LbyR URI in the subsequent DHCP 
OFFER or ACK, to deem the previously learned LbyR to be stale.

#2 (related to #1) We can discuss whether or not we want the DHCP 
process to simply remove this information from storage

#3 - keep it and somehow mark it as stale, but knowing this can give 
a rough location - instead of not knowing anything about where in the 
world the user agent is.

#4 - not mark it as stale

#5 other suggestions?

>I can see there being implementations that happily cache the URI and 
>keep using it.

see above, and offer a suggestion of which option (or new one) you'd 
like to see moving forward.

>client MUST store the URI delivered in the most recent DHCP message 
>it has received.  In particular, if the client receives a DHCP 
>message that does not contain this Option, then it MUST remove any 
>URIs it has previously received."

again - see above. Your suggestion is very much like how Options 1, 2 
and 3 related to reach other, but I'd like to get a sense from the 
group (and you) as to which you prefer to be the behavior.

James