Re: [Ecrit] ECRIT WG RECHARTER (Proposal Version 1)

["James M. Polk" <[e-mail]>]

At 05:00 AM 12/31/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>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

IMO, these are just new milestones - and don't need to be added to 
the text of the charter


>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).

thanks for including this text


>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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ecrit