-framework Brian Rosen

-11 version deals with IESG comments All comment resolved one way or another One open issue – spec(t)

Changes Deleted terms defined elsewhere rather than add more terms defined in the references – Made an exception for “PSAP” since it will really drive lazy readers nuts Replaced “GPS” with GNSS nearly everywhere Rewrote the text on “no 1-button emergency call” to make it very clear its advice and not normative in any way Replaced the accuracy for mobile from a 100 meters to “cannot be relied upon to be less than hundreds of meters” Rewote 9.3 to better specify how proxies decide whether to add location and/or route on behalf of an endpoint and to deal with anonymous emergency calls (regulatory matter) Fixed call back text to clear up Contact related issues (3261 says the right thing already) Added references to SDES for keying SRTP Fixed ¼ zillion nits

The spec(t) problem We want a P-A-I, if present, to be passed to the PSAP This is a domain boundary, and 3325 says you can only do that with a spec(t) that defines security We have two choices: 1.Leave it up to the PSAP to create the spec(t) with its usual suspects (carriers), wink at other carriers that send it but haven’t agreed to the spec(t) 2.Define a spec(t) in –phonebcp Text currently uses 1

-phonebcp Brian Rosen

-15 addresses AD comments Deleted commentary on how hard it is for proxies to determine local dialing strings Specified “all subservices in urn:service:sos” tree in ED-11 (what services the device deals with) Replaced “suitable” with “provided the accuracy of the location meets local requirements” in “Any location determination method MAY be used” Added “such that the location provided by the access network is available to clients as if the intermediate device was not in the path” in explaining what intermediate device (think APs) do. Reworded AN-9/10 to say “Uncertainty and confidence may be specified by local regulation. Where not specified, uncertainty of less than 100 m with 95% confidence is recommended for dispatch” Clarified the wording about L2 specific LCPs

changes Added new requirement “If the access network supports more than one location configuration protocol, all such protocols MUST return the same location, within the constraints of the protocols deployed.” Endpoints SHOULD try all LCPs supported by the device in any order or in parallel. The first one that succeeds in supplying location MUST be used (was “can”) Deleted made up backoff retry algorithm to HELD query Strengthened “… location update mechanisms MUST be implemented and used. ” Explained the 10 sec limit on location update of a value (via ReINVITE)

changes Added “If multiple locations are in a single PIDF, the procedures in [RFC5491] MUST be followed. If the proxy has multiple PIDFs, and has no reasonable basis to choose from among them, a random choice is acceptable” to proxy route Changed text to read “If S/MIME is used, the INVITE message MUST provide enough information unencrypted for intermediate proxies to encrypt route the call based on the location information included. This would include the SIP Geolocation header and any bodies containing location information. Use of S/MIME with emergency calls is NOT RECOMMENDED” Greatly simplified the requirements for LIS/LoST discovery. Lots of deleted text, what remains is the references to LIS Discovery and LoST discovery documents Fixed a problem where 5626 on persistent TLS connections did not cover proxy to proxy.

changes Deleted text that specified normal 3261 behavior in the signaling details requirement Deleted SIP caller preferences reference and language preference text, as it was borked Bunch of rewording for clarity without changing any requirements Renumbered requirements Deleted the sorted requirements appendices