[Ecrit] ECRIT WG RECHARTER (Proposal Version 1)

"Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> Wed, 31 December 2008 11:00 UTC

Return-Path: <ecrit-bounces@ietf.org>
X-Original-To: ecrit-archive@megatron.ietf.org
Delivered-To: ietfarch-ecrit-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2439D3A686C; Wed, 31 Dec 2008 03:00:06 -0800 (PST)
X-Original-To: ecrit@core3.amsl.com
Delivered-To: ecrit@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A6BD3A686C for <ecrit@core3.amsl.com>; Wed, 31 Dec 2008 03:00:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.554
X-Spam-Level:
X-Spam-Status: No, score=-5.554 tagged_above=-999 required=5 tests=[AWL=1.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZT1a+P4zyCG for <ecrit@core3.amsl.com>; Wed, 31 Dec 2008 03:00:03 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id E45E23A67ED for <ecrit@ietf.org>; Wed, 31 Dec 2008 03:00:02 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mBVAxolv030831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ecrit@ietf.org>; Wed, 31 Dec 2008 11:59:50 +0100
Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mBVAxoVk020095 for <ecrit@ietf.org>; Wed, 31 Dec 2008 11:59:50 +0100
Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 31 Dec 2008 11:59:50 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 31 Dec 2008 13:00:13 +0200
Message-ID: <C41BFCED3C088E40A8510B57B165C162F0AC6B@FIESEXC007.nsn-intra.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: ECRIT WG RECHARTER (Proposal Version 1)
thread-index: AclrNvTKdzIm1rzTSkGAIL2XpuYBfQ==
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: ECRIT <ecrit@ietf.org>
X-OriginalArrivalTime: 31 Dec 2008 10:59:50.0103 (UTC) FILETIME=[E6C7CE70:01C96B36]
Subject: [Ecrit] ECRIT WG RECHARTER (Proposal Version 1)
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ecrit-bounces@ietf.org
Errors-To: ecrit-bounces@ietf.org

Here is a proposal for ECRIT rechartering.
 
Please let me know if you disagree with something or if something is
missing 

Note that I was not quite sure whether it would be necessary to actually
include the following two items in the charter at all after the change
to the Service URN RFC has been made: 
* draft-forte-ecrit-service-classification
* draft-sun-ecrit-shelter-service

I believe they could be sent directly to the RFC editor and then the
review would be done by the ECRIT working group. 
Please provide me feedback on this issue. 

Ciao
Hannes

----------------

Emergency Context Resolution with Internet Technologies (ecrit)

Description of Working Group:

In a number of areas, the public switched telephone network (PSTN) has
been configured to recognize an explicitly specified number (commonly
one that is short and easily memorized) as a call for emergency
services.  These numbers (e.g. 911, 112) relate to an emergency
service context and depend on a broad, regional configuration of
service contact methods and a geographically-constrained context of
service delivery.  These calls are intended to be delivered to special
call centers equipped to manage emergency response. Successful
delivery of an emergency service call within those systems requires
both an association of the physical location of the originator with an
appropriate emergency service center and call routing to deliver the
call to the center.

Calls placed using Internet technologies do not use the same systems
to achieve those goals, and the common use of overlay networks and
tunnels (either as VPNs or for mobility) makes meeting them more
challenging.  There are, however, Internet technologies available to
describe location and to manage call routing.  This working group will
describe when these may be appropriate and how they may be used.
Explicitly outside the scope of this group is the question of
pre-emption or prioritization of emergency services traffic. This
group is considering emergency services calls which might be made by
any user of the Internet, as opposed to government or military
services that may impose very different authentication and routing
requirements.

The group will maintain and extend the Location to Service Translation 
(LoST) protocol for emergency services related aspects but also for 
usage outside the emergency services context. Additionally, the group
is chartered to work on descriptions and extensions regarding
citizen-to-
authority services (such as defining a Resource Priority header for 
usage with emergency services). 

While this group anticipates a close working relationship with groups
such as NENA and ETSI EMTEL, any solution presented must be useful
regardless of jurisdiction, and it must be possible to use without a
single, central authority.  Further, it must be possible for multiple
delegations within a jurisdiction to be handled independently, as call
routing for specific emergency types may be independent.

This working group cares about privacy and security concerns, and will
address them within its documents.

Goals and Milestones:

Done     Submit "Requirements for Emergency Context Resolution with
Internet Technologies" to the IESG for consideration as an Informational
RFC 
Done     Submit "Security Threats and Requirements for Emergency Call
Marking and Mapping" to the IESG for consideration as an Informational
RFC
Done     Submit "A Uniform Resource Name (URN) for Emergency and Other
Well-Known Services" to the IESG for consideration as a Standards Track
RFC 
Done     Submit "LoST: A Location-to-Service Translation Protocol" to
the IESG for consideration as a Standards Track RFC
Done     Submit "Discovering LoST Servers Using DHCP" to the IESG for
consideration as Informational RFC
Done     Submit "Location-to-URL Mapping Architecture and Framework" to
the IESG for consideration as an Informational RFC
Done     Submit "Location Hiding: Problem Statement and Requirements" to
the IESG for consideration as an Informational RFC
Done     Submit "Specifying Holes in LoST Service Boundaries" to the
IESG for consideration as a BCP RFC
Feb 2009 Submit "Synchronizing Location-to-Service Translation (LoST)
Servers" to the IESG for consideration as a Standards Track RFC
Feb 2009 Submit "Best Current Practice for Communications Services in
support of Emergency Calling" to the IESG for consideration as a BCP RFC
Feb 2009 Submit "Framework for Emergency Calling using Internet
Multimedia" to the IESG for consideration as a Standards Track RFC
Mar 2009 Submit "IANA Registering a SIP RPH Namespace for Local
Emergency Communications" to the IESG for consideration as a Standards
Track RFC
Mar 2009 Submit "RFC 5031bis" to the IESG for consideration as a
Standards Track RFC
Apr 2009 Submit "Using Imprecise Location for Emergency Context
Resolution" to the IESG for consideration as an Informational RFC
May 2009 Submit "Location-to-Service Translation Protocol (LoST)
Extensions" to the IESG for consideration as an Informational RFC
May 2009 Submit "LoST Classification of Location-based Services" to the
IESG for consideration as an Experimental RFC
May 2009 Submit "LoST Usage for discovering Shelter Services" to the
IESG for consideration as an Experimental RFC
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit