Internet Emergency Preparedness WG (ieprep) Minutes for Monday, March 18 at 1530-1730 =================================== CHAIR: Fred Baker Fred presented an overview and indicated that the BCP RFC should be completed by next IETF in Yokohama. Therefore, lots of work to be done on the mail list. Need to get documents in place so service providers can begin working with their governments on what is possible and how to contact for such emergency services. Currently 4 internet drafts have been submitted. http://www.ietf.org/internet-drafts/draft-baker-ieprep-requirements-00.txt http://www.ietf.org/internet-drafts/draft-brown-ieprep-sec-00.txt http://www.ietf.org/internet-drafts/draft-carlberg-ieprep-framework-00.txt http://www.ietf.org/internet-drafts/draft-folts-ieprep-white-paper-00.txt Comment: How can we get BCP without current practices? BCP is best way we know how to do something rather than the best way we ARE doing something. ===================================== Kimberly King presented overview on GETS. · GETS call is binary preferential treatment during call setup. No preemption of existing calls. · 1 out of 1000 calls was GETS call during 911 in NY, NY. · Converged Architecture with packet network presents new problems but similar to GETS. Comments: · Is GETS supported throughout the US? It is supported to some extent throughout US, but only has contracts with three of the service providers. · Issue raised on tracking emergency calls in Internet and attack those calls. · Question of authorization? GETS is SS7 centric not the same congestion issues for circuit switch vs. packet switching. · Question on how many GETS calls did not get through during 911. Statistics will be published to the list. · Is GETS all that emergency services want or what other services are being considered? · GETS has approximately 60,000 users in the US. · GETS does not help the case where you cannot get a dial tone. ==================================================== Ken Carlberg presented Framework for IEPREP Telephony GETS is target model, but mimics neither GETS nor the PSTN architecture. Framework looks at near and mid-term Core Objectives · High probability of call completion · Distinguish IEPS traffic · Interaction with PSTN · Non-preemptive action · Non-ubiquitous service · Authenticated service Value Added Objectives · Alternate path routing o Solutions using BGP are dead on arrival o One possible approach is application layer routing (e.g., TRIP) · End-to-End Fault Tolerance (FEC, redundant transmissions, etc… Functional Requirements · Signals and Signaling: Conveying information o SIP § Resource Header Draft · · NameSpace.Priority; values registered with IANA · DSN namespace for (5) priority values of MLPP § Proposed IEPS NameSpace to IANA · (1) value of "authorized-emergency" · Previous IEPS draft proposed (3) values o "authorized-emergency" o "general-emergency" e.g., 911 o "normal" § Comment: no relationship between 911 service and GETS § Comment: need to get ieprep information to SIP § GSN standards include 5 levels of priority o Diff-serv § Should be able to use existing code points § E.g., AF for SIP signaling, EF for voice § Data merge points in the cloud? Issue that needs to be revisited. § Should there be a new class for AF · More drop precedence values for emergency-type traffic? · Comment: What problems are trying to be solved by this? Also, research has shown than humans cannot distinguish between more than 3 or 4 levels of priority. · Comment: Question of QoS, generally emergency services does not require different QoS versus ability to complete call / message transfer? · Comment: How do we authenticate the request? Needs to be addressed. § Comment: Are we talking about diff-serv for signaling or diff-serv for data stream? Answer, Probably both, but needs some deep thought. o RTP § Propose a "Classifier" extension § To be removed from the framework draft § Downside · Potential reliance of S-RTP for authentication · Policy o Defining actions on what has been conveyed o E.g., preemption, resource allocation (and constraints) · Traffic Engineering · Security Scenarios · Backbone o NGN PSTN: e.g., IP at the core, SS7 at the edges o Stub domain: e.g. VoIP Things to do · Incorporate comments for IEPREP mail list Appendix Stuff · Describe Government Telephone Preference Scheme (GTPS) of the UK · Mention current snapshot of SG-11 & SG-16 work on priority/label field and relation to SIP R-P field · Comment: Next IETF and ITU Study Group 11 meetings may be in conflict. · Comment: ITU Study Group 16 is just beginning to look at emergency telecommunications and the study group 16 will be focal point for all emergency telecommunications within the ITU. Comment: ITU temporary documents are accessible to general public. =================================================================== James Polk provided overview of SIP resource Priority (Ongoing MLPP discussions in SIP) · Resource-Priority Header o Goal: § Establish preferential (or differential…) treatment Comment: Optional field. Lack of the option implies certain actions. Comment: STP is generally not accepted by proxies. Thus, it is rather hard to do authentication with STP. ================================================== Open Discussion: Comment: We need to distinguish voice, data and other services when we discuss the drafts. Fred: Need to distinguish policy from labels Comment: How should be handle policy? We need to separate policy from labeling. Comment: Service definition is done by the service provider. Fred: Policy is something we DO NOT want to specify in the standard. Comment: It appears we are assuming that the network is in working order. It appears there should be considerations of fallback positions. Should we consider backup systems, local hardening of the network, or other? Answers: That should be the service providers job. We shouldn't have to operate differently in an emergency. Comment: Public switch network is so large and calls turn over so fast that there is not need for multiple levels of priorities. However, we need multiple priorities in the landline network with limited resources so we need more levels of priority to ensure high probability of success. Comment: Issue of GETS to multiple levels in IP. Comment: How does mobile phone fit in? If there are no resource available in access network, then what? Fred will arrange an interim meeting in May/June in San Jose or Washington DC to discuss documents that are being worked.