Subject: [Ecrit] Proposal for a new requirement

From: "Stastny Richard" <[email-masked]>
Date: Wed, 14 Sep 2005 10:59:17 +0200

Dear all,

following the discussion on local access and VPN, I think

a new requirement is needed in section 5 "Identifying

the caller location" of the req I_D

It should go approx like this (the language may need work ;-)

Any device potentially be connected to the Internet and
used for contacting emergency services MUST be able to store

(multiple) retrieved location information and also MUST be able to provide
this location information at any time to requesting applications
running n this device. (so it is a function of the OS of the device).

The information stored should contain location (civic or geo), time
retrieved, source, verification status, etc. The information stored
may also contain URIs retrieved for different purposes ...

Motivation: Location information may be retrieved by the device
from different sources and at different times (e.g. via GPS, RFID,

User Input, DHCP and similar protocols, etc.). Some of this information
may be already retrieved at or shortly after power-on (without any 

connection to the Internet yet) and/or at time of (first) connection

to an IP-network e.g. retrieve an IP-address. Note: also at this time 

no connection or no full connection to the Internet may be provided. 

The location information provided at this first contact at this IP
layer MUST be kept, MUST NOT be updated by information provided by
later additional IP-layers and may eventually (by mobile devices) 

be updated underneath later. This location information MUST be retrievable
at any time, even if later an additional IP-layer is established LATER
(e.g via an VPN), and the mapping database, the MSAG and also the PSAP
in case of an emergency call is contacted via the VPN access.

I know this need work

feedback welcome

Richard

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 14 Sep 2005 04:38:07 -0500

Hi Richard,

I would prefer that it says that the device stores the location of the
device, or a reference to the device's location.

It must also stress that when the reference is accessed by an authorized
entity that the device's location must be surrendered.

Cheers
James

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Stastny Richard
> Sent: Wednesday, 14 September 2005 6:59 PM
> To: [email-masked]
> Subject: [Ecrit] Proposal for a new requirement
> 
> Dear all,
> 
> 
> 

------------------------------------------------------------------------------------------------
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]

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 14 Sep 2005 13:34:58 +0200

Hi James,
 
so you think the requirement makes sense in principle?
 
>device, or a reference to the device's location
 
Agree, there is some better wording needed that all retrieved locatons,
pointers to locations and also eventually retrieved URIs via DHCP (e.g to mapping DB
or PSAP ) need to be stored.

I do not fully understand this

You mean a pointer to location on the device?
On the device directly? or via remote access? - I do not think so
On the device you may retrieve the pointer as is
and then use it to access the LIS if you are authorized
so where is the problem?

Richard

________________________________

Von: Winterbottom, James [mailto:[email-masked]]
Gesendet: Mi 14.09.2005 11:38
An: Stastny Richard; [email-masked]
Betreff: RE: [Ecrit] Proposal for a new requirement

Hi Richard,

Cheers
James

Of

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 14 Sep 2005 06:57:48 -0500

Yes the last bit.
If you are authorized to get the location form the LIS using a LIS then
the LIS has to give it to you.

I think that the requirement makes sense.

> From: Stastny Richard [mailto:[email-masked]]
> Sent: Wednesday, 14 September 2005 9:35 PM
> To: Winterbottom, James; [email-masked]
> Subject: Re: [Ecrit] Proposal for a new requirement
> 
> Hi James,
> 
> pointers to locations and also eventually retrieved URIs via DHCP (e.g
to
> mapping DB
------------------------------------------------------------------------
--
> ----------------------
------------------------------------------------------------------------
--
> ----------------------

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 14 Sep 2005 15:47:00 -0500

>running n this device. (so it is a function of the OS of the device).

I do not have a problem with a requirement that more than one location 
format (civic, geo and URI) be stored.

Are you suggesting there may be a problem with internal (to the device) 
retrieval of each form of location?

Is this within the IETF's charter to mandate? I think we should recommend 
that an application running on a device have access to all forms of 
location stored within a device.

>retrieved, source, verification status, etc.

verification status sounds like validation, something we want, but cannot 
mandate, and do not know how to reasonably do. This is not part of the 
PIDF-LO, this is not part of DHCP, this cannot be part of an internal GPS 
chip...

>The information stored
>layer MUST be kept, MUST NOT be updated

or replaced

>by information provided by

I still don't know exactly what you are driving at here (other than the 
requirement *not* to overwrite location learned by the Link layer when a 
VPN is brought on-line).

>Richard

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 14 Sep 2005 23:09:14 +0200

>location stored within a device.

Correct

>PIDF-LO, this is not part of DHCP, this cannot be part of an internal GPS

Sorry, I meant validation. What I meant here was simply
that IF a civic location was validated e.g. via MSAG, this
should be noted.
 
>requirement *not* to overwrite location learned by the Link layer when a

yes

Richard

Von: James M. Polk [mailto:[email-masked]]
Gesendet: Mi 14.09.2005 22:47
An: Stastny Richard; [email-masked]
Betreff: Re: [Ecrit] Proposal for a new requirement

or replaced

cheers,
James

                                 *******************

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 14 Sep 2005 16:49:48 -0500

>that IF a civic location was validated e.g. via MSAG, this

While I fully agree that only civic addresses that are in the MSAG (or 
whatever alternative/future database is used) should be sent in the INVITE, 
one of several things will occur:

#1 - the ESRP will error the message with a 424 (Bad Location Information) 
error if the lcoation is not in the database

#2 - the ESRP will pass the location along (knowing or unknowing the 
validity of the information) and the PSAP will check this information to 
its database.

Now, one of a few things will happen:

A - The location information is good, the PSAP accepts the call;

or

B - The location information (in whichever format) is inaccurate/incorrect 
or otherwise bad, the PSAP will reject the INVITE because bad location 
information was in the INVITE (though not a likely scenario - so do we 
really need to keep discussing this topic?!)

or

C - the location information doesn't match up with the entry in the MSAG as 
a bad street name (or it's just not in the range of street addresses on a 
particular street in the database) and the PSAP operator is alerted to this 
as is forced to ask the person on the call "where are you?".

Doesn't this happen anyway?

cheers,
James

                                 *******************