ECRIT Architectural Considerations draft-polk-newton-ecrit-arch-considerations-01 James Polk Andrew Newton

Genesis An observation about the ECRIT meeting in Paris: New comers were confused Old hands speak about differing universes The intent of this document: Provide enough information for new comers Specify common parameters for the old hands In the process, identify some issues.

Architecture There is no one, single type of network in which ECRIT will be deployed. There are many. However, we can identify processes that occur within each type of network on which ECRIT must rely: Bootstrapping Conversion Mapping Conveyance

Bootstrapping Delivery of configuration and location information to “seekers”. DHCP PPP LLDP Manual There are multiple configuration protocols. The ECRIT requirements upon bootstrapping are not clear.

Conversion Syntactic Geocoding & Reverse Geocoding If no PIDF-LO compatible mapping protocol, from the binary bootstrapping scheme to mapping scheme. From the binary bootstrapping scheme to PIDF-LO XML for conveyance. Geocoding & Reverse Geocoding x,y,z <--> 123 Main St. Civic addresses are user friendly But geospatial coordinates can be more precise No requirements for the delivery of both.

Mapping Location Context Mapping System (LCMS) Static: Dynamic “fixed location” devices can have the mapping done beforehand and handed to them. Dynamic When location is known to be fluid, mapping can be done “on-the-fly”. Combination Endsystem always asks (same) trusted server where it is (before or during call), even when it moves within the local network

Conveyance Information sent to the PSAP during the emergency call Location Conveyance PIDF-LO A URI to PIDF-LO? Identity Conveyance An authenticated identity A call-back reference

Unresolved Issues Emergency Identifiers Security Considerations Data Distribution Extensibility Conflation

Emergency Call Identifier(s) Is there just: One? Three? Seven? What about adhoc identifiers specific to certain regions? Must these identifiers take any certain form to fit into protocol elements?

Security Considerations LCMS volume is likely to be orders of magnitude higher than PSTN emergency call volume. If bootstrapping protocols are insecure, what is the point anyway? What is the real problem? Mapping forgery Mapping denial of service

Data Distribution Most likely resolved with new ‘Re5’ requirement.

Extensibility Resolved by new ‘Ma15’ requirement: The mapping protocol MUST be extensible to allow for the inclusion of new location fields.

Conflation No requirements regarding the resilience of the emergency call resolution process as it relates to inputs that have not been designed for this specific purpose. E.g. ECRIT may require streets to be abbreviated or postal names to be absent, but other location based applications require “typical” addresses.