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

[Marc Linsner <[e-mail]>]

James,

In-line....


On 3/25/10 6:49 PM, "James Polk" <[e-mail]> wrote:

> At 03:50 PM 3/25/2010, Marc Linsner wrote:
>> 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.
> 

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-


> 
>> 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" <[e-mail]> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/geopriv
>>> 
>