Subject: [Geopriv] Location URI Metadata: the "possibly changes" flag

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 13 Jan 2009 14:04:25 -0500

This discussion of location URI metadata reminds me that we really do
need a way for the holder of a location URI to know if repeated
dereferencing is going to get a new location or not.  This has to be a
hint: I don't think there is any way to make a definitive statement that
it CAN'T, under any circumstances change.  However, the hint is very
valuable, and I'd pay a lot of complexity to get it if I have to.

I really don't care how we find this out.  For example, it would be fine
with me if this was an element of the PIDF you got the first time you
dereferenced.  It would be fine if it was somehow encoded in the URI.
It would be fine if was returned in the dereference operation itself.  I
don't care, as long as every scheme that can be used for a location URI
can return the bit somehow.

I'd define the bit as "possibly mobile": location MIGHT change over a
relatively short time.  I only need one bit; I get the most bang from
simply knowing if I should try.  I'd advise that a LIS serving things
like a wireline network, where, yes, it's possible that the ATA can be
moved between boot operations, but if you have a reasonably contemporary
dereference, it's unlikely to change.

Brian

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

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 13 Jan 2009 14:15:47 -0600

Brian

hmmm....

how does a wired phone in a mobile home that's connected to a router 
than then connects to either a satellite service or 3G cellular 
network know if it's moving or not to set the flag in the location 
URI it gives out as its geolocation?

I think this has been n argument that you have used successfully in 
the past to advocate that everything needs to be considered mobile, 
regardless of the UA's initial connectivity type.

This probably gets further complicated than just in the location URI, 
because the UA didn't ask for anything other than a location URI 
initially in its LCP (such as DHCP Option 99 or 123).  LLDP doesn't 
have this ability to indicate this in the request either. HELD 
doesn't at present, but appears to be the easiest to modify when in 
LCP mode (to indicate when asking for a location URI, that it is to 
be considered mobile - which I believe all HELD URIs believe in the 
first place, but that's perhaps a separate discussion) and could 
change soon so "go ahead and dereference as many times as you like, 
cuz the answer should be different this time"...

This seems inconsistent to indicate that something may be stationary 
or highly mobile, given that all things IP need to be considered 
mobile, and anything mobile can change in a short period of time, 
though not that every mobile UA changes locations with each query for 
its location URI.

I also question whether this will create a security threat that 
doesn't exist now.  One in which a pattern of indications can tell 
whether a location URI or a group of location URIs claim they are 
more mobile than other location URIs?

Regardless, this CANNOT be a mandatory flag, as I, for one, likely 
will not ever want to give out this information.

Which adds perhaps another requirement to this solution - if there is 
a solution for this -- how do I know if the location URI is 
explicitly NOT set to tell anyone this information, as a user? I will 
want to know that the location URI is one that doesn't reveal this 
information, even if I don't see the URI itself.  I know this is 
getting into the agreement portion of the contract between the user 
and service, but still... this is important to discuss here when 
discussing the requirements, don't you think?

James

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 13 Jan 2009 15:30:22 -0500

The access network knows if its mobile or not.  In your example, the access
network is the satellite or 3G cellular data network, and it would set the
bit in the location URI it provided to the wired phone.

The DSL network that provided location to the dual mode handset would
probably not.  But if the handset roamed off the 802.11 network on to a
cellular network, it's location URI has to change, because the access
network changed.

It's a hint; can't be relied upon.  Happy to have it default to "possibly
mobile", which is what it would have to do to avoid information leaking.  

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of James M. Polk
> Sent: Tuesday, January 13, 2009 3:16 PM
> To: Rosen, Brian; GEOPRIV
> Subject: Re: [Geopriv] Location URI Metadata: the "possibly changes"
> flag
> 
> Brian
> 
> hmmm....
>

---

From: Marc Linsner <[email-masked]>
Date: Tue, 13 Jan 2009 15:40:58 -0500

Brian,

> mobile", which is what it would have to do to avoid information leaking.

OK, simply consider all locations "possibly mobile".  What's the down side
of thinking a stationary device might be mobile?

-Marc-

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 13 Jan 2009 14:50:12 -0600

>of thinking a stationary device might be mobile?

I think he's trying to get at the stationary devices that won't move 
month to month, and separating them from the truly mobile 
phones.  I'm just weary that this will give out information to the 
location seeker that the target doesn't want revealed necessarily.

Doing it the way he wants would reduce the number of dereferences 
made though, so there is some benefit - but I'm not sure it's 
something that would necessarily create a large advantage to a server 
answering the dereferences, which should have its own timer of how 
many times does the same location URI get dereferenced by the same 
source.  This alone would cut down on the DOS attacks.

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 13 Jan 2009 16:45:56 -0500

Unnecessary load on the LIS.  You want a hint if repeatedly dereferencing
(or setting up a subscribe/notify that persists for a while) is worth it.

Brian

> From: Marc Linsner [mailto:[email-masked]]
> Sent: Tuesday, January 13, 2009 3:41 PM
> To: Brian Rosen; James Polk; Rosen, Brian; 'GEOPRIV'
> >>> It would be fine if was returned in the dereference operation
> itself.
> >> I

---

From: Marc Linsner <[email-masked]>
Date: Tue, 13 Jan 2009 17:01:02 -0500

Brian,

Please provide the use case you have in mind.

As Polk mentioned, there are those that will play connect-the-dots with bits
of data, which could turn into an unintended leak of private information.

-Marc-

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 13 Jan 2009 17:14:46 -0500

Emergency call: should the PSAP query the LIS repeatedly, or should it do it
once?
Standard presence package: instantiate a subscription with a long duration,
looking for updates, or dereference once in a (relatively long) while?

Brian

> Sent: Tuesday, January 13, 2009 5:01 PM
> To: Brian Rosen; 'GEOPRIV'
> >>> The access network knows if its mobile or not.  In your example,
> the
> >> access
> >>> probably not.  But if the handset roamed off the 802.11 network on
> to
> >> a
> >> OK, simply consider all locations "possibly mobile".  What's the
> down
> >> side
> >>>>> This discussion of location URI metadata reminds me that we
> really
> >> do
> >>>>> hint: I don't think there is any way to make a definitive
> statement
> >>>> that
> >>>>> I really don't care how we find this out.  For example, it would
> be
> >>>> fine
> >>>>> don't care, as long as every scheme that can be used for a
> location
> >>>> URI
> >>>>> I'd define the bit as "possibly mobile": location MIGHT change
> over
> >> a
> >>>>> like a wireline network, where, yes, it's possible that the ATA
> can
> >> be

---

From: Marc Linsner <[email-masked]>
Date: Tue, 13 Jan 2009 17:41:07 -0500

Brian,

What is your prediction of the load Emergency Services will put on the
location architecture in comparison to all other LIS/LS traffic?

I'll make a wager that ES is way less than 1%.

This isn't worth the effort, imo.

-Marc-

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 13 Jan 2009 16:27:51 -0600

Hi Brian,

I think that Marc has it right - there is no harm in assuming that the location can change.  I can see why you would consider the converse to be a useful assumption, but there is such a narrow band of applicability that it's better to go with the mobile assumption.

This all seems to come down to loading.  And in response: subscription-like mechanisms seem to work quite well by removing polling.  Caching also helps a fair amount.  And, if you do need to poll in an emergency, the cost is going to be outweighed by the possible benefit (i.e., you are going to poll anyway, and cost be damned).

I'd like to repackage your proposal to see if you can see our perspective:

 - Location URI metadata: "stationary" flag

 An indicator on a location URI that indicates that there is a high likelihood that the Target is stationary.  This provides an optimisation (for non-subscription cases) where a location recipient can avoid polling for location information.

Does that sound like a reasonable proposal to you?  Can you provide use cases for this one?

Cheers,
Martin

> Behalf Of Brian Rosen
> Sent: Wednesday, 14 January 2009 9:15 AM
> To: 'Marc Linsner'; 'GEOPRIV'
> > As Polk mentioned, there are those that will play connect-the-dots
> with
> > bits
> > > (or setting up a subscribe/notify that persists for a while) is
> worth
> > it.
> > >
> > > Brian
> > >
> > >>> network is the satellite or 3G cellular data network, and it
> would
> > >> set the
> > >>>> though not that every mobile UA changes locations with each
> query
> > >> for
> > >>>> its location URI.
> > >>>>
> > >>>> Which adds perhaps another requirement to this solution - if
> there
> > >> is
> > >>>>> dereferencing is going to get a new location or not.  This has
> to
> > >> be a
> > >>>>> with me if this was an element of the PIDF you got the first
> time
> > >> you
> > >>>>> dereferenced.  It would be fine if it was somehow encoded in
> the
> > >> URI.
> > >>>>> relatively short time.  I only need one bit; I get the most
> bang
> > >> from

------------------------------------------------------------------------------------------------
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]
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: Richard Barnes <[email-masked]>
Date: Tue, 13 Jan 2009 19:40:55 -0500

Brian,

This might be better handled in the dereference protocol than in the 
reference itself.

By way of analogy, think about HTTP: How does an HTTP client know 
whether the content he's just accessed is going to change?  (Or, 
equivalently, whether it should be cached.)  This problem arised long 
ago in the context of HTTP, and there are several cache-control headers 
(e.g., Expires) that tell clients and their proxies when to check back.

A dereference protocol based on HTTP (or HELD) could probably make use 
of this model directly  Just tag the response with an Expires header, 
with a long time if you're stationary, and a short one if you're mobile. 
  Other dereference protocols might need additional semantics.

In any case, I don't think I would list this as a requirement for a 
reference system, but I agree it would be pretty handy.

--Richard

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 13 Jan 2009 18:47:45 -0600

More than just this.
The timed presence extensions described in RFC4481 clearly allow the LIS
to specify how long a specific location will be valid for, this is a far
more useful mechanism for stipulating the relatively stationary nature
of a Target and putting a flag in a URI.

Cheers
James

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Richard Barnes
Sent: Wednesday, 14 January 2009 11:41 AM
To: Rosen, Brian
Cc: GEOPRIV
Subject: Re: [Geopriv] Location URI Metadata: the "possibly changes"
flag

Brian,

--Richard

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 14 Jan 2009 08:47:17 -0500

Problem solved.  This will do fine.  Thanks for the suggestion.

Brian

> Behalf Of Winterbottom, James
> Sent: Tuesday, January 13, 2009 7:48 PM
> To: Richard Barnes; Rosen, Brian
> Cc: GEOPRIV