Re: [Ecrit] WG Review: Emergency Context Resolution with Internet Technologies (ecrit)

[Randall Gellens <[e-mail]>]

I support the proposed new charter.


At 9:28 AM -0800 11/22/13, The IESG wrote:

>  The Emergency Context Resolution with Internet Technologies (ecrit)
>  working group in the Real-time Applications and Infrastructure Area of
>  the IETF is undergoing rechartering. The IESG has not made any
>  determination yet. The following draft charter was submitted, and is
>  provided for informational purposes only. Please send your comments to
>  the IESG mailing list (iesg at ietf.org) by 2013-12-02.
>
>  Emergency Context Resolution with Internet Technologies (ecrit)
>  ------------------------------------------------
>  Current Status: Active WG
>
>  Chairs:
>    Marc Linsner <[e-mail]>
>    Roger Marshall <[e-mail]>
>
>  Assigned Area Director:
>    Richard Barnes <[e-mail]>
>
>  Mailing list
>    Address: [e-mail]
>    To Subscribe: https://www.ietf.org/mailman/listinfo/ecrit
>    Archive: http://www.ietf.org/mail-archive/web/ecrit/
>
>  Charter:
>
>  In a number of areas, the public switched telephone network (PSTN) has
>  been configured to recognize an explicitly specified number (usually one
>  that is short and easily memorized) as a request for emergency services.
>
>  These numbers (e.g., 911, 112) are related to an emergency service
>  context and depend on a broad, regional configuration of service contact
>  methods and a geographically-constrained approach for 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 an association of
>  both the physical location of the originating device  along with
>  appropriate call routing to an emergency service center.
>
>  Calls placed using Internet technologies do not use the same systems
>  mentioned above to achieve those same goals, and the common use of
>  overlay networks and tunnels (either as VPNs or for mobility) makes
>  meeting these goals even more challenging.  There are, however, Internet
>  technologies available to manage location and to perform call routing.
>
>  This working group has described where and how these mechanisms may be
>  used. The group specified how location data and call routing information
>  are  used to enable communication between a user and a relevant emergency
>
>  response center [RFC6443,RFC6444]. Though the term "call routing" is
>  used,
>  it should be understood that some of the mechanisms described might be
>  used
>  to enable other types of media streams.
>
>  Beyond human initiated emergency call request mechanisms, this group will
>
>  develop new methods to enable non-human-initiated requests for emergency
>  assistance, such as sensor initiated emergency requests.
>
>  The working group will also address topics required for the operation of
>  emergency calling systems, such as:  authentication of location,
>  management
>  of the service URN namespace, augmented information that could assist
>  emergency call takers or responders.
>
>  Explicitly outside the scope of this group is the question of pre-
>  emption or prioritization of emergency services traffic in the network.
>  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, EENA, 3GPP, and ETSI , any solution presented must be
>  general enough to be potentially useful in or across multiple regions or
>  jurisdictions, and it must be possible to use without requiring a
>  single, central authority.  Further, it must be possible for multiple
>  delegations within a jurisdiction to be handled independently, things
>  such as call routing for specific emergency types, media types,
>  language contents, etc.,  may be routed differently depending on
>  established policies and availability.
>
>  This working group will address privacy and security concerns within its
>  documents.
>
>
>
>  Milestones:
>    Done     - 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
>    Done     - Submit 'Location Hiding: Problem Statement and Requirements'
>  to the IESG for consideration as an Informational RFC.
>    Done     - Submit 'Framework for Emergency Calling using Internet
>  Multimedia' to the IESG for consideration as an Informational RFC.
>    Done     - Submit 'Best Current Practice for Communications Services in
>  support of Emergency Calling' to the IESG for consideration as a BCP
>  document
>    Done     - Submit 'LoST Extension for returning Boundary Information
>  for Services' to the IESG for consideration as an Experimental RFC
>    Done     - Submit 'Synchronizing Location-to-Service Translation (LoST)
>  Protocol based Service Boundaries and Mapping Elements' to the IESG for
>  consideration as an Experimental RFC
>    Done     - Submit 'Public Safety Answering Point (PSAP) Callbacks' to
>  the IESG for consideration as an Informational RFC
>    Done     - Submit 'Extensions to the Emergency Services Architecture
>  for dealing with Unauthenticated and Unauthorized Devices' to the IESG
>  for consideration as a Standards Track RFC
>    Nov 2013 - Submit 'Common Alerting Protocol (CAP) based Data-Only
>  Emergency Alerts using the Session Initiation Protocol (SIP)' to the IESG
>  for consideration as an Experimental RFC
>    Nov 2013 - Submit 'Trustworthy Location Information' to the IESG for
>  consideration as an Informational RFC
>    Dec 2013 - Submit 'Additional Data related to a Call for Emergency Call
>  Purposes' to the IESG for consideration as a Standards Track RFC
>    Dec 2013 - Submit a draft 'Policy for defining new service-identifying
>  labels' to the IESG for consideration as BCP
>    Dec 2013 -  Submit a draft 'URN For Country Specific Emergency
>  Services' to the IESG for consideration as a Standards Track RFC
>    Mar 2014 - Submit 'Using Imprecise Location for Emergency Call Routing'
>  to the IESG for consideration as an Informational RFC
>
>
>  _______________________________________________
>  Ecrit mailing list
>  [e-mail]
>  https://www.ietf.org/mailman/listinfo/ecrit



-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
I never travel without my diary.  One should always have something
sensational to read on the train.
    --Oscar Wilde