50 likes | 67 Views
NENA geopriv Requirements. draft-rosen-nena-geopriv-requirements-00 Brian Rosen. Integrity of Location Information. When location is forged, and used for an emergency calls, responders are dispatched incorrectly, which can cause harm
E N D
NENA geopriv Requirements draft-rosen-nena-geopriv-requirements-00 Brian Rosen
Integrity of Location Information • When location is forged, and used for an emergency calls, responders are dispatched incorrectly, which can cause harm • Location may go through multiple protocols and representations (e.g. DHCP, then SIP) • Need end to end signature over the location
Multiple Locations • When multiple locations are given in a PIDF-LO, or multiple PIDF-LOs are transported in a message, what does that mean? • For emergency calls, we can’t have unresolvable ambiguity; we route on ONE location • BUT sometimes there is a default (more coarse grained) location, PLUS a more accurate one (tower location vs handset location). Need to deal with that. • Need rules/guidelines/fields to figure out how to do this
Other changes needed • Need “Postal Community” and “Legal” Community fields • Need Date/Time location was determined (when PIDF-LO was created may be useful for integrity protection) • Confidence and Uncertainty is not enough information. Need more work • Need more “Placetypes” (?SIMPLE?) • Need other information associated with location (or caller)
What do we want to do? • Recharter geopriv to deal with these issues • Turn this into one or more requirement/solution documents that get accepted as WG items