2.8.4 Internet Emergency Preparedness (ieprep)

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-01-14

Scott Bradner <sob@harvard.edu>
Kimberly King <kimberly.s.king@saic.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@psg.com>
Transport Area Advisor:
Allison Mankin <mankin@psg.com>
Mailing Lists:
General Discussion: ieprep@ietf.org
To Subscribe: ieprep-request@ietf.org
In Body: subscribe ieprep
Archive: ftp://ftp.ietf.org/ietf-mail-archive/ieprep/
Description of Working Group:
Effective telecommunications capabilities are imperative to facilitate immediate recovery operations for serious disaster events, such as, hurricanes, floods, earthquakes, and terrorist attacks. Disasters can happen any time, any place, unexpectedly. Quick response for recovery operations requires immediate access to any public telecommunications capabilities at hand. These capabilities include: conventional telephone, cellular phones, and Internet access via online terminals, IP telephones, and wireless PDAs. The commercial telecommunications infrastructure is rapidly evolving to Internet-based technology. Therefore, the Internet community needs to consider how it can best support emergency management and recovery operations.

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.

Goals and Milestones:
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.
  • - draft-ietf-ieprep-framework-04.txt
  • - draft-ietf-ieprep-security-01.txt
  • - draft-ietf-ieprep-requirements-01.txt
  • - draft-ietf-ieprep-packet-marking-policy-01.txt
  • - draft-ietf-ieprep-reflexive-dscp-01.txt
  • - draft-ietf-ieprep-reference-00.txt
  • - draft-ietf-ieprep-sip-reqs-03.txt
  • - draft-polk-ieprep-scenarios-03.txt
  • - draft-ietf-ieprep-ets-telephony-02.txt
  • - draft-ietf-ieprep-ets-general-02.txt
  • No Request For Comments

    Current Meeting Report

    IEPREP Meeting Notes
    Internet Emergency Preparedness WG (ieprep)
    Wednesday, March 19 at 1300-1500 
    CHAIRS: Scott Bradner   <sob@harvard.edu> 
            Kimberly King   <kimberly.s.king@saic.com>
    		agenda bashing	
    5 minutes
                    James Polk
    10 minutes
                    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
    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".
    	don't refer to VoIP as "other elastic application"
    	change "carriers" to "telephony carriers"
    expand the reference of "higher probability" to refer to call 
    	removed term "centralized authentication" in reference to PSTN 
    security model
    	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
    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 
    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 
    Scott Bradner: and authorization
    Eric Rescorla : If we cannot simulate the problem, how can we test a 
    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 
    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 
    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)
    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.
    Janet Gunn: The one thing in the charter that we haven't played with is the 
    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 
    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 
    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.


    ITU-T status report: ieprep-related activities
    IEPREP Control/Data Plane Considerations
    General Requirements (v2)