Subject: RE: [Geopriv] "PossibyMobile" attribute in PIDF-LO

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 23 Aug 2006 10:34:55 -0400

Oh, more complex things are okay. I rather like the TTL for location.  I
don't think we should change the definition of the retention period.
That's a security mechanism and has validity beyond the point where the
location represents where you actually are.

The flag is helpful.  TTL may be more helpful.

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Wednesday, August 23, 2006 10:30 AM
> To: Rosen, Brian
> Cc: GEOPRIV
> Subject: Re: [Geopriv] "PossibyMobile" attribute in PIDF-LO
> 
> There are two possibly more general solutions:
> 
> - timed-presence, where the source can indicate how long it
> anticipates the location to be valid. If the location-information is
> coarse-grained, even a highly mobile device may have information that
> is valid for minutes or hours.
> 
> - stretching the definition a bit, the LO retention period.
> 
> Thus, I'm not convinced that a simple flag is all that helpful. Just
> about any device in California is mobile if you wait long enough.
> 
> Henning
> 
> On Aug 23, 2006, at 9:46 AM, Rosen, Brian wrote:
> 
> > We need a flag in PIDF-LO that indicates that the location supplied
> > may
> > change over time periods of less than normal lease times of IP
> > addresses.  It can't be reliable, that is, it can't guarantee the
> > location WILL change, only that it could, and therefore needs to be
> > refreshed before it is used.
> >
> > Take the following scenario:
> >
> > A hardwired VoIP phone, sold for use in a fixed enterprise
environment
> > is connected to an Ethernet switch, which is plugged into a small
> > router.  The router uplink is a GPRS (or EvDO, or Satellite) radio
> > modem.  The entire network is installed in an RV, and is "moving
down
> > the highway, looking for adventure" in Montana.  The phone is on a
VPN
> > to an IP-PBX located in, of course, Sierra Leone.
> >
> > Let's say the phone acquired its location from somewhere.  For the
> > moment, don't worry about how that happened.  Suppose the phone
> > makes an
> > emergency call.
> >
> > Somehow, the phone has to know it should retry its location
> > acquisition
> > query and get a new location before it places the call.  That's
> > what the
> > flag is for.
> >
> > We'll also need this flag in the DHCP location options, and someone
> > ought to tell the LLDP-MED guys.
> >
> > Brian
> >
> > _______________________________________________
> > Geopriv mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/geopriv

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

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 23 Aug 2006 11:43:57 -0500

Brian

hard phones think they're hardwired.  In your RV scenario:

- what in the phone would tell it it's mobile?

- what in the router has access to the non-LLDP/DHCP messaging to tell the 
hard wired phone it is not on a building desktop?

The router itself has to understand mobility in this case, to inform (via 
LLDP or DHCP) anything on the client side of it to refresh for location 
prior to making the call.

Taking your example one step further, say that RV has a .11 radio, but 
doesn't know it's mobile.  The .11 IP phone will refresh its location to 
the router, but the router may not have known it too was moving down the road.

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 23 Aug 2006 14:19:58 -0400

Well, let's take a for-instance.

Suppose that the radio link supports SUPL, and the router supports DHCP.
The router gets location from the uplink via SUPL, and supplies location
to the phone via DHCP.  SUPL is obviously a mobile network protocol.

In the .11 case, the AP is the DHCP server, and although its uplink
supplied location would not have the PossiblyMobile set, when it gave
location to its clients, it would set it.

Brian

> From: James M. Polk [mailto:[email-masked]]
> Sent: Wednesday, August 23, 2006 12:44 PM
> To: Rosen, Brian; Henning Schulzrinne
> Cc: GEOPRIV
> Subject: RE: [Geopriv] "PossibyMobile" attribute in PIDF-LO
> 
> Brian
> 
> the router, but the router may not have known it too was moving down
the
> road.

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 23 Aug 2006 14:49:47 -0400

Again, we can call it anything we want, I don't care.

A wifi roaming system might supply civic, and GML wouldn't be used.  I'm
not familiar with the GML motion mechanism, but it sounds like event
notification, which would complicate a lot of things outside of a
presence subscription.

Happy to copy anything that works rather than reinventing the wheel.

Brian

> From: Ted Hardie [mailto:[email-masked]]
> Sent: Wednesday, August 23, 2006 2:44 PM
> To: Roger Marshall; Rosen, Brian; GEOPRIV
> At 7:30 AM -0700 8/23/06, Roger Marshall wrote:
> >Brian:
> >It sounds like you're saying, "since it May be mobile, then treat it
as
> >mobile".
> >
> >Why not simply call it, "mobile", there doesn't seem to be a
difference
> >between doing a location refresh (update) for a client that might be
> >mobile, and one that is known to be mobile.
> >
> >Roger Marshall
> 
> I agree with Roger.  "mobile" is a characteristic meaning "movable";
> it does not always mean that something is in motion or that it moves
> with any consistency.  If you feel that we need a characteristic for
> "movable", let's discuss that, rather than "possibly movable".
> 
> Past that, though, I am concerned that we are fixing this in the wrong
> layer.  The key element you want is to  update the location  provided
> to a device when its geographic location has changed but its place in
> the network topology has not.   GML has facilities for both motion and
> validity periods that we chose not to pull in to PIDF-LO; now you seem
to
> be
> saying that in the absence of those we should create a trigger that
must
> fire either before every communication or after some TTL.  The first
risks
> increasing latency at a critical moment, and the second is largely
wasted
> traffic.  Why is the right answer not either adopting the GML
facilities
> or
> recommending folks use location provision mechanisms capable of update
> if they are "movable" without changes to their place in the topology?
> 
> 				regards,
> 					Ted Hardie