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

2. 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.

3. 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

4. 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.

5. 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.

6. 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

7. 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

8. Unresolved Issues Emergency Identifiers Security Considerations
Data Distribution
Extensibility
Conflation

9. 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?

10. 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

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

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

13. 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.