RE: [Ecrit] Emergency Context Routing of Internet Technologies -Architecture Considerations

"Abbott, Nadine B" <nabbott@telcordia.com> Fri, 09 September 2005 15:25 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDklK-00054J-RR; Fri, 09 Sep 2005 11:25:58 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDklE-00051f-C8 for ecrit@megatron.ietf.org; Fri, 09 Sep 2005 11:25:56 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09837 for <ecrit@ietf.org>; Fri, 9 Sep 2005 11:25:50 -0400 (EDT)
Received: from dnsmx1pya.telcordia.com ([128.96.20.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDkon-00058W-T5 for ecrit@ietf.org; Fri, 09 Sep 2005 11:29:36 -0400
Received: from rrc-its-ieg01.cc.telcordia.com (rrc-its-ieg01.cc.telcordia.com [128.96.109.78]) by dnsmx1pya.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id j89FPe611388 for <ecrit@ietf.org>; Fri, 9 Sep 2005 11:25:40 -0400 (EDT)
Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by rrc-its-ieg01.cc.telcordia.com (SMSSMTP 4.0.5.66) with SMTP id M2005090911202431336 for <ecrit@ietf.org>; Fri, 09 Sep 2005 11:20:24 -0400
Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 9 Sep 2005 11:25:37 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Ecrit] Emergency Context Routing of Internet Technologies -Architecture Considerations
Date: Fri, 09 Sep 2005 11:25:53 -0400
Message-ID: <A09345776B6C7A4985573569C0F3004306D824B5@rrc-dte-exs01.dte.telcordia.com>
Thread-Topic: [Ecrit] Emergency Context Routing of Internet Technologies -Architecture Considerations
Thread-Index: AcWzDLiV1AdT9CjESNKUKI1twQLfgwCPTcbA
From: "Abbott, Nadine B" <nabbott@telcordia.com>
To: ecrit@ietf.org
X-OriginalArrivalTime: 09 Sep 2005 15:25:37.0268 (UTC) FILETIME=[BA9C5340:01C5B552]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
Content-Transfer-Encoding: quoted-printable
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
Sender: ecrit-bounces@ietf.org
Errors-To: ecrit-bounces@ietf.org

James and Andy,

I appreciate your contribution to additional discussion of architectural
considerations that provide a context for the focus of on requirements
for location-based mapping protocols in the ECRIT discussions.  I think
this is very helpful.

I have a few observations and suggestions:

In section 1, a suggested definition for
Location Information Server (LIS) -- Provides a mapping function to
relate unique identifiers for IP devices at physical network access
points and the geographic descriptions of their location (e.g., civic
location/street addresses or geographic coordinates).  Responds to
queries for location information.

In Section 2, the list of methods for delivering configuration and
location information to the client does not include  the proposed HELD
method for IP clients to acquire location information from an Internet
access provider (described in HTTP Enabled Location Delivery [HELD],
draft-winterbottom-http-location-delivery-01).  This should be to be
added to the list to address the needs of a number of potential Internet
access providers that would be called upon to provide location
information in North America.

In Section 4, I suggest the addition of a paragraph with wording
something like the following to include an example of an ESRP concept
previously described in Section 6.1 of I-D: "Emergency Services for
Internet Telephony Systems," Henning Schulzrinne, October 18, 2004,
draft-schulzrinne-sipping-emergency-arch-02.
        
      At the option of the PSAP, more than one ESRP function may be
implemented in series, 
      to provide increasingly precise routing to the appropriate PSAP. 
      This allows for simplification of emergency call routing at the
originating network, 
      and for decision-making at local jurisdictional or at aggregate
levels for 
      real-time control of call routing.  This might also allow for some
additional jurisdictional 
      control of the visibility of emergency call routing information.

Thanks again,

Nadine Abbott  

-----Original Message-----
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf
Of Tschofenig, Hannes
Sent: Tuesday, September 06, 2005 1:59 PM
To: ecrit@ietf.org
Subject: [Ecrit] Emergency Context Routing of Internet Technologies
-Architecture Considerations


hi all, 

james and andy just submitted a draft with the following content:

"
   This document discusses architectural considerations for emergency 
   context routing of Internet technologies.  The purpose of this 
   document is to provide a systemic view of emergency context routing,
   discuss unresolved issues, and explain the relationship of some of 
   the proposals to these issues, while discussing potential directions 
   that might be still be necessary for the working group to 
   investigate.  
"

i have copied the draft to
http://www.ietf-ecrit.org/cache/draft-polk-newton-ecrit-arch-considerati
ons-00.txt

thanks to both of them for touching a number of interesting discussion
topics. 

ciao
hannes

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit