Last Modified: 2003-01-14
Three examples of emergency communications include:
1. Conveying information about the priority of specific phone calls that originate in a VoIP environment through gateways to the PSTN.
2. Access and transport for database and information distribution applications relevant to managing the crisis. One example of this is the I am Alive (IAA) system that can be used by people in a disaster zone to register the fact that they are alive so that their friends and family can check on their health.
3. Interpersonal communication among crisis management personnel using electronic mail and instant messaging.
Initial documents will describe the problem space and its salient characteristics. In particular the working group will devlop a Requirements for Internet Emergency Preparedness in the Internet RFC which will detail the specific functions and technologies needed to provide support for Emergency Preparedness systems in the Internet. The working group may also develop a Framework for Supporting Internet Emergency Preparedness in IP Telephony RFC if it is determined that IP telephony requires special treatment above what would be in the requirements document.
The international community needs advice as to what standards to rely on, in the form of a BCP. This BCP needs to identify mechanisms to provide deterministic behavior of applications, mechanisms for authentication and authorization, and recommendations for application design with existing protocols. In the IETF considerations for treatment and security of emergency communications stretch across a number of Areas and Working Groups, notably including the various telephony signaling working groups, Differentiated Services, Protocol for carrying Authentication for Network Access (pana), and various operational groups, so the IEPREP working group will have to cooperate closely with these groups and with groups outside of the IETF such as various ITU-T study groups.
The working group will develop a BCP RFC or set of RFCs, regarding operational implementation of services for Emergency Preparedness using existing Internet protocols. The RFC may include identification of gaps in existing protocols and requirements for use in new protocol or protocol feature design. It is out of scope for this working group to do protocol or protocol feature development. The working group will not focus on particular national regulations.
Best Current Practice: IETF Recommendations for the Emergency Telecommunications Service using existing protocols - what can be done with existing protcols and what can not be done.
Informational: Requirements for Internet Emergency Preparedness in the Internet. Framework for Supporting Internet Emergency Preparedness in IP Telephony.
|MAR 02||Submit initial I-D of Requirements|
|MAR 02||Submit initial I-D of Framework|
|MAR 02||Submit initial I-D of Recommendations BCP|
|AUG 02||Submit Requirements I-D to IESG for publication as an Informational RFC.|
|AUG 02||Submit Framework I-D to IESG for publication as an Informational RFC.|
|AUG 02||Submit Recommendations I-D to IESG for publication as a BCP.|
IEPREP Meeting Notes Internet Emergency Preparedness WG (ieprep) Wednesday, March 19 at 1300-1500 ================================ CHAIRS: Scott Bradner <email@example.com> Kimberly King <firstname.lastname@example.org> AGENDA: agenda bashing Chairs 5 minutes draft-polk-ieprep-flow-model-considerations-00.txt James Polk 10 minutes draft-ietf-ieprep-framework-04.txt draft-ietf-ieprep-ets-telephony-02.txt draft-ietf-ieprep-ets-general-02.txt Ken Carlberg 20 minutes ETS progress at the ITU Stephen Perschau 10 minutes ieprep next steps Group discussion 25 minutes ---------- 70 minutes James Polk -> flow model considerations Informative document on an information track Delineate the control plane from the data plane Signaling/Control Plane between the responder and initiator Data plane between the responder and initiator Major change will be to add a new diagram And change wording around QoS Questions: An email suggestion to add SAP, but unsure of its relevance. Ken Carlberg -> ETS General Requirements Changing IPprep to IPPREP Changing "better than best effort" around application layer mechanisms to "other than best effort". Changing: don't refer to VoIP as "other elastic application" change "carriers" to "telephony carriers" expand the reference of "higher probability" to refer to call completion removed term "centralized authentication" in reference to PSTN security model TBD: refer to Genuity and Sprint Traffic Engineering in Atlanta IETF request for discussion of service that makes a positive difference original comments aimed at general requirements More to be added (but perhaps premature): DCCP -> spec due on Dec' 03 NSIS UDP-Lite Questions: Dennis Berg: I am trying to understand the character of a framework document vs. a best practices document, etc. It seems to not go all the way in coming out with a set of requirements Scott Bradner: This is an IETF meta-question, frameworks are not meant to be specific. Frameworks describe the environment in which we are playing. The requirements are how to build the swing set. Frameworks are not descriptions of what you must do but describe the environment. Dennis Berg: Are we going to move forward with a requirements documents? Not quite clear: high probability of completion and guarantee of completion objective of not expecting every network or portion of a call path to be enhanced with this work. In other words, partial deployment is a compromise, not a goal. Scott Bradner: An absolute requirement for absolute reliability would imply more resources, i.e. more bandwidth. Dennis Berg: should just say to do a little bit better (perfect would be the panacea, but...) at least. Janet Gunn: One of the requirements that I would like to see is if there is a call admission process, that there is priority in the call admission process (call setup), even if it means simply trying again (and this goes in the telephony requirements doc). Ken Carlberg: That type of requirement would be in ip tel requirement document. He asks Janet to sent some potential text for the document. Bill Woodcock: These problems aren't network related the network is already doing better than PSTN call completion, so the expectation between circuit-switched network and packet-switched network folks is completely at odds. Scott Bradner: We postulate that the backbone isn't the issue, but problems are more in the access networks such as cable networks or enterprise networks. Bill Woodcock: We keep requiring methods, not service requirements, and no one has demonstrated that calls are not being completed, so is there really a problem? Scott Bradner: Some people want it and will pay for it so let them do so. Bill Woodcock: That is not what IETF is here for. No one has demonstrated that there is a problem. Scott Bradner: If there is no need then it will die its death and we don't need lots of protocol development anyway. James Polk: Just because there hasn't been an issue doesn't mean there won't be one Dick Knight: I am agreeing that the problem is in the access network, not the backbone. Scott Bradner: also the gateway Dick Knight: How does one do authentication, massive processing, etc. in a congested environment? There isn't enough information about this in the drafts. Scott Bradner: and authorization Eric Rescorla : If we cannot simulate the problem, how can we test a solution? Janet Gunn: There aren't a great deal of SIP phones at this point, and there will be critical mass at some point Dave Crocker: Theoretical possibility of the infrastructure being a problem is real, and the potential damage is significant, so placing concern is good. The question is resources, and this working group has yet to produce so focus on the backbone should only be done after other issues have been solved. Peter Lothberg: Who is the operator that is the problem here? There is decoupling between the access point and the backbone provider. Dennis Berg: I have a procedural question. What is the relationship between your documents and Henning's RFC 3487, is there order of precedence and overlap? Or a contradiction? Greg Woodhouse: In D.C. on 9/11, and the cell phone was his only means of communication. Stephen Perschau -> ITU-T progress E.106 description of an International Emergency Preference Scheme for Disaster Relief Operations adding support for packet networks Supplement to J.160 architectural framework for the delivery of time-critical services over cable data networks J.ETS new recommendation addressing emergency telecom over cable data networks Study Group 11 including support for an international codepoint for ETS Study Group 16 Question I use of public telecom services for emergency and disaster relief operations Study Items identify organizations addressing the various aspects related to telecom for emergency and disaster relief operations working on security aspects for authentication of users and prevention of interference TDR standardization (British Telco's might not be reimbursed if ETS term was used in place of TDR so the name was changed) Questions: Brian Rosen: The codepoint in SG 11 is an ISUP codepoint right? IEPREP Next Steps: Scott Bradner: We should not assume that the backbone is a part of the problem at the moment. Comments: Janet Gunn: The one thing in the charter that we haven't played with is the BCP John Gilmore: To what extent is the discussion here to deny service to non-authorized users? Will non-authorized traffic simply be dropped? Scott Bradner: I'm reluctant to support turning off everyone. I think civilian should communicate just as much as government. I suggest few ISPs to convert to ETS only as their customers wouldn't stand for it. John Gilmore: Some governments declare "emergency" to curb communications. Steve Silverman: if the prioritized traffic is less than 10% of the rest, the impact is small. Dan Romascanu: The issue of E911 traffic hasn't been addressed here. Thorsten Claus (?): from a SP perspective, how can I invest money in building my network for working with the government? Are there any business cases? Janet Gunn: Money is paid for service provider and to the vendor for software changes for GETS capability, maybe that will happen here... I have never seen any desire to block non-authorized traffic for any reason other than call completion. There has never been any intention to make this only available to government workers. There is a precedence for putting in mechanisms for limiting the GETS type traffic. Brian Rosen: One should not assume that this is only for voice. Dave Knight: Globally, the US is not paying other countries to put this stuff in (applause). Dennis Berg: Service Providers are paranoid about E911 traffic. Should make a note about the position about IEPREP capabilities vs. E911 support. Janet Gunn: working on 911 issues for WPS, the PSAPS do not want preferential treatment. Human resources are the constrained resource. Keith Dredge: can E911 be out of the scope for this group? Scott Bradner: E911 is being worked in SIPPING. E911 is out of scope for IEPREP. Jon Peterson: believes that working on the access points, links, and enterprise networks is going to be time consuming and difficult but says okay if IEPREP has the stomach for it.