Subject: [Geopriv] dhcp-lbyr-uri-option

From: Marc Linsner <[email-masked]>
Date: Thu, 25 Mar 2010 09:28:04 -0400

>From section 1:

" A problem exists within existing RFCs that provide location to the
   UA ([RFC3825] and [RFC4776]). These DHCP Options for geolocation
   values require an update of the entire location information (LI)
   every time a client moves.  Not all clients will move frequently,
   but some will.  Refreshing location values every time a client moves
   does not scale in certain networks/environments, such as IP-based
   cellular networks, enterprise networks or service provider networks
   with mobile endpoints.  An 802.11 based access network is one
   example of this. Constantly updating LCI to endpoints might not
   scale in mobile (residential or enterprise or municipal) networks in
   which the client is moving through more than one network attachment
   point, perhaps as a person walks or drives with their client down a
   neighborhood street or apartment complex or a shopping center or
   through a municipality (that has IP connectivity as a service).

   If the client were provided a location URI reference to retain and
   hand out when it wants or needs to convey its location (in a
   protocol other than DHCP), a location URI that would not change as
   the client's location changes (within a domain), scaling issues
   would be significantly reduced to needing an update of the location
   URI only when a client changes administrative domains - which is
   much less often.  This delivery of an indirect location has the
   added benefit of not using up valuable or limited bandwidth to the
   client with the constant updates.  It also relieves the client from
   having to determine when it has moved far enough to consider asking
   for a refresh of its location.
"

I don't understand the statements above.  IETF LCPs don't constantly update
endpoints with LCI. Just like dereferencing a uri, endpoints can reuse the
LCP mechanism to gain access to it's (newly changed) location.  In both
mechanisms, LCP or URI deref, the location determination mechanism is
invoked by the LIS/LS at that time.  I just don't get the proposed benefit.

What am I missing?

-Marc-

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 25 Mar 2010 15:14:17 -0500

>invoked by the LIS/LS at that time.  I just don't get the proposed benefit.

weeellll -- if you want cubical or office level accuracy/resolution, 
or if you want to know which floor you are on (all from the 
perspective of the device), where devices move frequently - either 
you update the location (e.g., this particular DHCP Option 99/123)) 
often (probably at certain intervals) via a push from the LIS/DHCP 
server, or your client requests updated Option 99/123 whenever it 
detects it has moved.

Either way - there is LI being transmitted frequently, but only if 
either end (client or server) is configured to do this.

Conversely, if your client only asks for a Location URI, you don't 
have (however often you move or the network updates your location) 
repeated LCI pushes or pulls, which take up BW.

The point of this document is optimization of location delivery. Get 
the URI Option once, and you don't (really) need an update to the 
Option until your client changes admin domains due to moving outside 
of Starbucks' dot11 coverage area and into Joe's Pizza shop and ISP 
coverage area, for example.

Do you believe this optimization makes sense?

Do you believe this optimization makes sense, but needs to be written 
more clearly?

Or, do you believe Location URIs don't make sense?

James

>What am I missing?
>
>-Marc-
>
>
>_______________________________________________
>Geopriv mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/geopriv

---

From: Marc Linsner <[email-masked]>
Date: Thu, 25 Mar 2010 16:50:51 -0400

James,

I guess my confusion comes from the section I pulled out as it talks about
LCI, which is only offered to a target.  Also, I'm not aware that either
DHCP or HELD are capable of a 'push'.  So, I'm not seeing the added value in
a target dereferencing a URI to get LbyV vs. performing additional LCP LbyV
queries.  In either case, the target does a 'query'.

Is this section stating the LbyR handed out via the LCP is a SIP sub/notify?

I understand the value of a URI when someone other than the target is
wanting location.

Am I making any sense?

-Marc-

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 25 Mar 2010 17:49:53 -0500

>queries.  In either case, the target does a 'query'.

with the Location URI Option, the client does this query once, and 
not again until the client changes domains or at some URI refresh 
interval. Within a Cisco campus, the location URI - once learned - 
will remain valid while the client is within the campus -- regardless 
of how many APs it traverses in its travels around the campus.

With a client receiving an Option 99/123, it needs to re-query every 
time the client believes it has traveled sufficiently to know it's 
location value is old information. Changing APs is the easy part for 
triggering a new query for LI, moving between floors on the same AP isn't.

>Is this section stating the LbyR handed out via the LCP is a SIP sub/notify?

sip:
sips:
pres:
http:
https:

are now all valid URIs to be given out.

>I understand the value of a URI when someone other than the target is

yes - these are good questions. LMK if I've answer you well enough

James

---

From: Marc Linsner <[email-masked]>
Date: Fri, 26 Mar 2010 09:21:49 -0400

James,

In-line....

> triggering a new query for LI, moving between floors on the same AP isn't.

OK, this is the part I'm missing.  The algorithm the client uses to decide
when to re-query is the same no matter what location discovery mechanism is
being used, is it not?  What is the advantage to dereferencing a URI vs.
sending a DHCP option request or a HELD request?  I see them as equal, no
advantage to one over the other in this use case.

My only reason for commenting is the draft proposes that in the case of LCI,
which is a target discovering it's own location, there are advantages to
LbyR vs. DHCP or HELD.  I'm not convinced there is any advantage.  I'm
simply attempting to make the text in the draft accurate.

-Marc-