Emergency Context Resolution with Internet Technologies (ecrit) Internet Drafts

      
 A LoST extension to return complete and similar location info
 
 draft-ietf-ecrit-similar-location-19.txt
 Date: 04/03/2022
 Authors: Brian Rosen, Roger Marshall, Jeff Martin
 Working Group: Emergency Context Resolution with Internet Technologies (ecrit)
 This document describes an extension to the LoST protocol of RFC 5222 that allows additional civic location information to be returned in a . This extension supports two use cases: First, when the input location is valid but lacks some Civic Address elements, the LoST server can provide a completed form. Second, when the input location is invalid, the LoST server can identify one or more feasible ("similar") locations. This extension is applicable when the location information in the request uses the Basic Civic profile as described in RFC 5222 or another profile whose definition provides instructions concerning its use with this extension.
 Validation of Locations Around a Planned Change
 
 draft-ietf-ecrit-lost-planned-changes-11.txt
 Date: 19/11/2024
 Authors: Brian Rosen
 Working Group: Emergency Context Resolution with Internet Technologies (ecrit)
 This document defines an extension to the Location to Service Translation (LoST) protocol (RFC5222) that allows a LoST server to notify a client of planned changes to location data. This extension is only useful with the validation function of LoST. It is beneficial for LoST validation clients to be aware of planned changes, since at a known future date, previously valid records may become invalid, and new records may become valid. This extension adds an element to the request to allow a LoST client to request validation as of a specified date. It adds an optional Time-To-Live element to the response, which informs clients of the current expected lifetime of a validation. It also adds a separate interface to a LoST server that allows a client to poll for planned changes. Additionally, this document provides a conventional XML schema for LoST, as a backwards compatible alternative to the RelaxNG schema in RFC5222.
 Emergency Registries
 
 draft-rosen-ecrit-emergency-registries-02.txt
 Date: 18/10/2024
 Authors: Brian Rosen, Brandon Abley
 Working Group: Emergency Context Resolution with Internet Technologies (ecrit)
 Multiple emergency services standards organizations are developing specifications based on IETF emergency calling and other IETF protocols. There is a desire among these organizations to use common registries, not tied to a particular country or national Standards Development Organization (SDO), in the long term pursuit of a single worldwide standard. This document asks IANA to create a set of registries and provides processes for expanding the set and populating them.

data-group-menu-data-url="/group/groupmenu.json">

Emergency Context Resolution with Internet Technologies (ecrit)

WG Name Emergency Context Resolution with Internet Technologies
Acronym ecrit
Area Applications and Real-Time Area (art)
State Active
Charter charter-ietf-ecrit-04 Approved
Document dependencies
Additional resources Issue tracker, Wiki, Zulip stream
Personnel Chairs Brandon Abley, Randall Gellens
Area Director Murray Kucherawy
Liaison Contacts Marc Linsner, Roger Marshall
Mailing list Address ecrit@ietf.org
To subscribe https://www.ietf.org/mailman/listinfo/ecrit
Archive https://mailarchive.ietf.org/arch/browse/ecrit/
Chat Room address https://zulip.ietf.org/#narrow/stream/ecrit

Charter for Working Group

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

Date Milestone Associated documents
Nov 2022 Submit 'Validation of Locations Around a Planned Change' to the IESG for consideration as a Standards Track RFC draft-ietf-ecrit-lost-planned-changes

Done milestones

Date Milestone Associated documents
Done 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 rfc8876 (was draft-ietf-ecrit-data-only-ea)
Done Submit ‘A LoST extension to return complete and similar location info‘ to the IESG for consideration as an Informational RFC draft-ietf-ecrit-similar-location
Done Submit ‘Next-Generation Pan-European eCall‘ to the IESG for consideration as an Informational RFC
Done Submit ‘Internet Protocol-based In-Vehicle Emergency Calls‘ to the IESG for consideration as an Informational RFC
Done Submit 'Additional Data related to a Call for Emergency Call Purposes' to the IESG for consideration as a Standards Track RFC
Done Submit 'A Routing Request Extension for the HELD Protocol' to the IESG for consideration as a Standards Track RFC
Done Submit a draft 'URN For Country Specific Emergency Services' to the IESG for consideration as a Standards Track RFC
Done Submit 'Trustworthy Location Information' 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
Done Submit 'Public Safety Answering Point (PSAP) Callbacks' to the IESG for consideration as an Informational 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 'LoST Extension for returning Boundary Information for Services' to the IESG for consideration as an Experimental 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 'Location Hiding: Problem Statement and Requirements' to the IESG for consideration as an Informational RFC.
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 Informational RFC containing terminology definitions and the requirements
Done A Standards Track RFC describing how to identify a session set-up request is to an emergency response center
Done An Informational document describing the threats and security considerations