[Sipping-emergency] Re: Emergency-req: 8-12

Henning Schulzrinne <hgs@cs.columbia.edu> Mon, 24 February 2003 04:02 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20286 for <sipping-emergency-archive@odin.ietf.org>; Sun, 23 Feb 2003 23:02:41 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1O4B3q13611 for sipping-emergency-archive@odin.ietf.org; Sun, 23 Feb 2003 23:11:03 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O4B2p13608 for <sipping-emergency-web-archive@optimus.ietf.org>; Sun, 23 Feb 2003 23:11:02 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20281 for <sipping-emergency-web-archive@ietf.org>; Sun, 23 Feb 2003 23:02:10 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O4B1p13594 for <sipping-emergency-web-archive@ietf.org>; Sun, 23 Feb 2003 23:11:01 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O4Arp13576 for <sipping-emergency@optimus.ietf.org>; Sun, 23 Feb 2003 23:10:53 -0500
Received: from mtiwmhc11.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20275 for <sipping-emergency@ietf.org>; Sun, 23 Feb 2003 23:02:00 -0500 (EST)
Received: from cs.columbia.edu (5.indianapolis-19rh15rt.in.dial-access.att.net[12.85.4.5]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <2003022404055311100ee5v4e>; Mon, 24 Feb 2003 04:05:54 +0000
Message-ID: <3E599978.8070906@cs.columbia.edu>
Date: Sun, 23 Feb 2003 23:03:04 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "James M. Polk" <jmpolk@cisco.com>
CC: sipping-emergency@ietf.org
References: <4.3.2.7.2.20030222120157.024467d0@localhost> <3E55EA9F.FB3489BB@lmf.ericsson.se> <4.3.2.7.2.20030217161831.047e6110@localhost> <3E516A89.90901@cs.columbia.edu> <3E55EA9F.FB3489BB@lmf.ericsson.se> <4.3.2.7.2.20030222120157.024467d0@localhost> <4.3.2.7.2.20030223115500.022b4da8@localhost>
In-Reply-To: <4.3.2.7.2.20030223115500.022b4da8@localhost>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Subject: [Sipping-emergency] Re: Emergency-req: 8-12
Sender: sipping-emergency-admin@ietf.org
Errors-To: sipping-emergency-admin@ietf.org
X-BeenThere: sipping-emergency@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping-emergency>, <mailto:sipping-emergency-request@ietf.org?subject=unsubscribe>
List-Id: <sipping-emergency.ietf.org>
List-Post: <mailto:sipping-emergency@ietf.org>
List-Help: <mailto:sipping-emergency-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping-emergency>, <mailto:sipping-emergency-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

> 
> Patrik Fältström is one of my coworkers who is part of this discussion 
> within Cisco frequently. This is his tenuous definition - though he 
> speaks it not in the absolute sense, but hesitantly as it hasn't been 
> agree upon anywhere in the community. My use it as a guide, though 
> opinions vary (obviously).

Pardon my timidity, but I'd rather not use this document to attempt a 
definition of Internet beyond the generally understood "a network of 
networks"... If Patrik wants to write a separate draft to clarify the 
internet/Internet/intranet/whatever distinction for current needs, it 
would be appropriate to cite it.


>> Note that the text speaks of finding the correct IECC, not of 
>> determining the location. The idea is that if a UA knows its location 
>> (via whatever means, including the ones you mention), it can directly 
>> query a location-to-IECC mapping service and then contact the IECC.
> 
> 
> But.... doesn't the UA *not* know the IP address of the PSAP? If it 
> doesn't in the INVITE, then the Proxy has to direct the INVITE (with the 
> sos@) towards the proper PSAP. This will require the Proxy to know which 
> PSAP to do to (unless there is only one in the area - in the case of a 
> large regional service). Maybe I'm missing something...?

Assumptions: (1) UA knows its own location, e.g., long/lat.
(2) UA knows at least one translation service that converts long/lat to 
ECC identity. How the UA knows this service is a matter of 
configuration, but it might be reasonable to assume that these lookup 
services change rarely. (Even if one were to go out of business, since 
the query interface is standardized, it would be trivial for the 
survivor to buy the address at the Chapter 7 sale...)

These assumptions are not unreasonable since there are commercial 
services that offer this type of service. They are currently not 
designed to be used by millions of users, but this seems like a problem 
that good system engineering could solve. The problem is much more 
tractable than even the most modest-sized search engine, say, both in 
terms of query rate (a few queries/second), stability of the data and 
number of entries (thousands).

Process: UA contacts this abstract service and gets back the SIP URI of 
the geographically appropriate ECC.

Is this clearer?

> 
>> This model has trust advantages since the UA can choose whatever 
>> mapping service it considers trustworthy ahead of time, get back a 
>> reply it can trust (since it presumably has made sure it's talking to 
>> the right directory service) and can then easily use standard server 
>> authentication mechanism to detect that it is indeed talking to the 
>> desired IECC. This makes the trust problem much more tractable. In 
>> effect, the caller gets to choose its "PSAP certifying authority" 
>> without every PSAP having to be accredited by one certifying authority.
> 
> 
> That will never happen

I'm trying to avoid the discussion of this since we will likely not get 
anywhere speculating. I'm trying to point out ways that we can avoid 
needing central authorities, while not preventing their emergence. In my 
opinion, we should provide the best (most reliable, secure, scalable, 
...) tools possible and then help the operational community do the right 
thing.

> how hard would this be to include in something like a DHCP configuration 
> download? Or have the UA periodically do something like an OPTIONs query 
> to the Proxy it knows, and exchange the necessary information to learn 
> the available choice in the background.

The data volume remains the same, so I'm not sure how "background" helps.

In any event, the draft now mentions synchronization-of-local-data as 
one possibility. Since this is a requirements document, I'm trying to 
exhaustively list all possible options, not pick favorites. Abstractly, 
I don't see any other possibilities beyond "UA knows itself" (local 
data), "UA asks somebody" (UA queries network directory) or "UA asks 
somebody that asks somebody" (UA sends request to proxy that queries 
directory or has local knowledge; this can recurse, obviously).

Henning

_______________________________________________
Sipping-emergency mailing list
Sipping-emergency@ietf.org
https://www1.ietf.org/mailman/listinfo/sipping-emergency