datatracker.ietf.org
Sign in
Version 5.3.0, 2014-04-12
Report a bug

Emergency Context Resolution with Internet Technologies
charter-ietf-ecrit-04

WG Review Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: ecrit WG <ecrit@ietf.org> 
Subject: WG Review: Emergency Context Resolution with Internet Technologies (ecrit)

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 <marc.linsner@cisco.com>
  Roger Marshall <rmarshall@telecomsys.com>

Assigned Area Director:
  Richard Barnes <rlb@ipv.sx>

Mailing list
  Address: ecrit@ietf.org
  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



WG Action Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: ecrit WG <ecrit@ietf.org> 
Subject: WG Action: Rechartered Emergency Context Resolution with Internet Technologies (ecrit)

The Emergency Context Resolution with Internet Technologies (ecrit)
working group in the Real-time Applications and Infrastructure Area of
the IETF has been rechartered. For additional information please contact
the Area Directors or the WG Chairs.

Emergency Context Resolution with Internet Technologies (ecrit)
------------------------------------------------
Current Status: Active WG

Chairs:
  Marc Linsner <marc.linsner@cisco.com>
  Roger Marshall <rmarshall@telecomsys.com>

Assigned Area Director:
  Richard Barnes <rlb@ipv.sx>

Mailing list
  Address: ecrit@ietf.org
  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



Ballot Announcement