-framework brian rosen. -11 version deals with iesg comments all comment resolved one way or another...

9
-framework Brian Rosen

Upload: denis-lane

Post on 27-Dec-2015

212 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: -framework Brian Rosen. -11 version deals with IESG comments All comment resolved one way or another One open issue – spec(t)

-framework

Brian Rosen

Page 2: -framework Brian Rosen. -11 version deals with IESG comments All comment resolved one way or another One open issue – spec(t)

-11 version deals with IESG comments

• All comment resolved one way or another• One open issue – spec(t)

Page 3: -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

Page 4: -framework Brian Rosen. -11 version deals with IESG comments All comment resolved one way or another One open issue – spec(t)

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

Page 5: -framework Brian Rosen. -11 version deals with IESG comments All comment resolved one way or another One open issue – spec(t)

-phonebcp

Brian Rosen

Page 6: -framework Brian Rosen. -11 version deals with IESG comments All comment resolved one way or another One open issue – spec(t)

-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

Page 7: -framework Brian Rosen. -11 version deals with IESG comments All comment resolved one way or another One open issue – spec(t)

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)

Page 8: -framework Brian Rosen. -11 version deals with IESG comments All comment resolved one way or another One open issue – spec(t)

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.

Page 9: -framework Brian Rosen. -11 version deals with IESG comments All comment resolved one way or another One open issue – spec(t)

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