>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'.
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
>wanting location.
>
>Am I making any sense?
yes - these are good questions. LMK if I've answer you well enough
James
>-Marc-
>
>On 3/25/10 4:14 PM, "James Polk" <jmpolk@cisco.com> wrote:
>
> > At 08:28 AM 3/25/2010, Marc Linsner wrote:
> >> 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.
> >
> > 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
> >> Geopriv@ietf.org
> >> https://www.ietf.org/mailman/listinfo/geopriv
> >
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
