Re: [Ecrit] ECRIT WG Rechartering

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

At 08:39 AM 10/27/2008, Richard Barnes wrote:
>I think there are a few milestones missing from this charter:

I think, but could be wrong, that only one of these IDs (Henning's) 
has been presented to the WG.  That usually limits their ability to 
be a WG item yet.


>-- A Standards-Track document describing how SIP messages related to
>emergency calling are distinguished from other
>messages(draft-patel-ecrit-sos-parameter)
>3GPP have made it pretty clear (both on this list and last week at the
>emergency services workshop) that this mechanism or something like it is a
>requirement for their emergency calling system.
>
>-- An Informational document describing requirements for emergency calling
>by unregistered or unauthenticated devices.
>(draft-schulzrinne-ecrit-unauthenticated access)
>This is an issue that ECRIT has avoided for a long time, as other SDOs have
>been developing mechanisms.  It would be useful to have an Internet-level
>analysis to unify these lower-level approaches and guide their development.
>
>-- An Informational document describing best practices for emergency
>calling from autonomous devices (vs. human callers)
>(draft-rosen-ecrit-ecall)
>Lots of different organizations (e.g., EU eCall and OGC's sensor web) are
>interested in having sensors or other devices place emergency calls.  These
>efforts could be more interoperable and better aligned with the ECRIT
>architecture if it were made explicit which subset of the ECRIT framework
>these systems should use.
>
>Cheers,
>--Richard
>
>
>
>On Tue, Oct 14, 2008 at 10:13 AM, Tschofenig, Hannes (NSN - 
>FI/Espoo) <<mailto:[e-mail]>[e-mail]> wrote:
>Here is a first proposal for the ECRIT WG rechartering based on the
>discussions we had around IETF#72.
>For the moment, I have put 3 additional documents onto the charter:
><http://tools.ietf.org/id/draft-polk-ecrit-local-emergency-rph-namespace-03.txt>http://tools.ietf.org/id/draft-polk-ecrit-local-emergency-rph-namespace-
>03.txt
>http://tools.ietf.org/id/draft-barnes-ecrit-rough-loc-00.txt
><http://tools.ietf.org/id/draft-forte-ecrit-lost-extensions-00.txt>http://tools.ietf.org/id/draft-forte-ecrit-lost-extensions-00.txt
>
>Regarding the following two documents
><http://tools.ietf.org/id/draft-forte-ecrit-service-classification-00.txt>http://tools.ietf.org/id/draft-forte-ecrit-service-classification-00.txt
>http://tools.ietf.org/id/draft-sun-ecrit-shelter-service-00.txt
>I am waiting for additional feedback from the draft authors on how they
>perceive these documents should be progressed through the IETF, see my
>mail here:
><http://www.ietf.org/mail-archive/web/ecrit/current/msg05518.html>http://www.ietf.org/mail-archive/web/ecrit/current/msg05518.html
>
>Please take a look at it and give me feedback till the 21st October
>2008.
>
>------------------------------------------------------------------------
>---------------------------
>
>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. 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.
>
>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.
>
>The group will work on the maintainance of the
>Location-to-Service Translation (LoST) protocol, on (emergency services
>and non-emergency services related)extensions to LoST to the as well as
>on necessary extension related to emergency call routing.
>
>This working group cares about privacy and security concerns, and will
>address them within its documents.
>
>Goals and Milestones:
>
>Done            An Informational RFC containing terminology definitions
>and the requirements
>Done            An Informational document describing the threats and
>security considerations
>Done            A Standards Track RFC describing how to identify a
>session set-up request is to an emergency response center
>Done            A Standards Track RFC describing how to route an
>emergency call based on location information
>Done            An Informational document describing the Mapping
>Protocol Architecture
>Dec 2008        An Informational document describing the ECRIT Framework
>Dec 2008        A BCP document describing the emergency call support for
>devices
>Oct 2008        An Informational document providing a problem statement
>and requirements for location hiding
>Oct 2008        An Informational document specifying how to express
>holes in LoST service boundaries
>Dec 2008        An Informational document describing how to synchronize
>LoST servers
>Jan 2009        A Standards Track RFC registering a SIP Resource
>Priority Header Namespace for Local Emergency Communications
>Feb 2009        An Informational document describing how imprecise
>location is used for emergency context resolution
>Feb 2009        A Standards Track RFC containing Location-to-Service
>Translation Protocol (LoST) Extensions
>_______________________________________________
>Ecrit mailing list
><mailto:[e-mail]>[e-mail]
>https://www.ietf.org/mailman/listinfo/ecrit
>
>
>_______________________________________________
>Ecrit mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ecrit

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