[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
- [Ecrit] ECRIT WG RECHARTER (Proposal Version 1) Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [Ecrit] ECRIT WG RECHARTER (Proposal Version … James M. Polk