2.7.6 Internet Emergency Preparedness (ieprep)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-05-19


Scott Bradner <sob@harvard.edu>
Kimberly King <kimberly.s.king@saic.com>

Transport Area Director(s):

Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>

Transport Area Advisor:

Jon Peterson <jon.peterson@neustar.biz>

Mailing Lists:

General Discussion: ieprep@ietf.org
To Subscribe: ieprep-request@ietf.org
In Body: subscribe ieprep
Archive: http://www.ietf.org/mail-archive/web/ieprep/index.html

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.

  Requirements for Internet Emergency Preparedness in the Internet.
  Framework for Supporting Internet Emergency Preparedness in IP

Goals and Milestones:

Done  Submit initial I-D of Requirements
Done  Submit initial I-D of Framework
Done  Submit initial I-D of Recommendations BCP
Done  Submit Requirements I-D to IESG for publication as an Informational RFC.
Done  Submit Framework I-D to IESG for publication as an Informational RFC.
Dec 03  Submit Recommendations I-D to IESG for publication as a BCP.


  • draft-ietf-ieprep-framework-10.txt
  • draft-ietf-ieprep-domain-req-04.txt
  • draft-ietf-ieprep-domain-frame-04.txt

    Request For Comments:

    RFC3487 I Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)
    RFC3523 I Internet Emergency Preparedness (IEPREP)Telephony Topology Terminology
    RFC3689 I General Requirements for Emergency Telecommunication Service
    RFC3690 I IP Telephony Requirements for Emergency Telecommunication Service

    Current Meeting Report

    IEPREP Working Group Meeting at IETF-63

    The IEPREP Working Group was chaired by Kimberly King at the Paris
    on Monday August 1, 2005. (Scott Bradner, the other Co-Chair, was unable

    to attend the Paris IETF meeting but was listening to the audio stream.)

    Minutes by Greg Bain with editorial assistance by Ken Carlberg

    The Agenda was as follows:

    5 minutes: agenda bashing
    25 minutes: Ieprep re-charter discussion
    15 minutes: Antonio DeSimone: DoD Requirements
    15 Minutes: An Nguyen: NCS Presentation

    There were no objections to the agenda.

    Kimberly introduced the new proposed charter of Ieprep for discussion having explained that the proposed revised charter had been posted to the ieprep list before the meeting.

    Kimberly outlined important points, including some work being done in other existing Working Groups, specifically highlighting the following from the proposed charter:

    "If there is an existing WG that can discuss the requirements for extending their protocol or mechanism, IEPREP will generate only a requirements document for that group to discuss.

    If there is not an existing WG that can discuss the requirements for extending their protocol or mechanism, IEPREP will prepare requirements and discuss the extension of that protocol/mechanism or protocols/mechanisms within IEPREP."

    James Polk:
    The charter is good. James suggested that something be added to the proposed charter. The addition could take into account other applications that may not be under way by other groups. Priority e-mail is a prime example of one of these. James said that many things are "inferred" in the charter, i.e., not explicitly stated, but understood.

    Ken Carlberg:
    Question to James Polk, What is the status of your documents in TSV (Transport Services Working Group)?

    Area Director Jon Peterson:
    It is obvious that there has not been much procedural progress in TSV, but this will be addressed shortly.

    James Polk:
    James recommended that we continue to move forward in TSVWG with those documents that are already in TSVWG.

    Question for Kimberly: Has anything been received privately on comments positive or negative on the new proposed charter?

    Tony DeSimone sent comments and he will speak to this question.

    Tony DeSimone:
    I did have a few comments on language because there is work going on in other forums.
    Nested VPNs is an example of such work. There are language issues where differences in definitions apply.

    Kwok Ho Chan:
    Will the MLPP draft be done here?

    Jon Peterson:
    It will proceed in TSVWG.

    Kwok Ho Chan:
    We are jumping to solutions instead of doing more requirements? The MLPP draft is more than requirements. Will the group be thinking about additional possible solutions?

    We hope to not presuppose solutions.

    Kwok Ho Chan:
    Does the charter state MLPP is the framework?

    The MLPP framework is posed as an example.

    Kwok Ho Chan:
    We need to work out the requirements first before assuming specific solutions.

    We can make the charter clearer with respect on how we propose to go forward using some documents as an example.

    James Polk:
    Words in the charter say "could serve as a framework." This wording implies more than one framework, including a solution within the charter.

    Fred Baker:
    To Kwok, are you working on an alternative framework?

    Kwok Ho Chan:
    Yes, we are willing to work on the framework document and contribute to this WG.

    Fred Baker:
    We need to understand how this works towards the solution.

    Kwok Ho Chan:
    We can work with the WG on this.

    Joe Babiarz:
    This WG should have requirement and understanding of requirement before having framework to work toward solutions.

    Jon Peterson:
    We have to be careful in the charter when working toward solutions. For example, in the case of e-mail, Ieprep may be stepping on the toes of the applications Area. We should coordinate a reference with them.

    James Polk:
    In the case of prioritised e-mail, if we cannot find a home for it, then

    it should be done here. Perhaps we can put in the charter if there is not a clear Area for certain applications, then it should be done here.

    Jon Peterson:
    I recommend we make the charter clearer here (for this particular example).

    To the group: Is anybody opposed to the charter in the spirit as it is currently written?

    James Polk:
    I want to know the scope of the different words that are being proposed?
    James, to Kwok, please present these words on the mailing list.

    Kwok Ho Chan:
    Lets do this on the WG mailing list.

    Jon Peterson:
    To Kimberly, ask for consensus.

    The hum indicated support for the proposed charter in its current spirit, with wording to be worked out on the mailing list. - There was not any hum in opposition.

    Kimberly then asked Tony DeSimone to give his presentation, i.e., the next Agenda item.

    Precedence and Pre-emption for the GIG transport Service

    Global Information Grid Network. (GIG)

    GIG is an organizing construct for a number of programs across the US Department of Defence and the Intelligence Community. Various GIG WGs are working on requirements across a variety of programs.

    One of these WGs is developing a strategy for precedence and pre-emption. The Challenge for GIG is not just voice, but other applications for all programs in the DOD and intelligence community.

    GIG is really looking at the requirements for precedence and pre-emption. Requirements come from a number of documents. CJCSI 6215.02A is a draft document where 6 precedence levels are called out. Different types of data need to be transferred across the networks. Higher priority data needs to be transferred before lower priority data.

    The history of this work goes back to analog networks. Taking circuit world requirements and solutions and moving to new services is the focus.

    James Polk:
    Question on bullet 3 (on additional features), are you implying nothing needs to happen in the network and that you only need to inform the user of the pre-emption?

    Tony DeSimone:
    To James, you are asking something beyond the bullet, your statement that nothing needs to happen in the network is not the intent of bullet 3.

    Stu Goldman:
    Bullet 2: In the circuit world you either have the priority or you don Does bullet 2, in regard to lower precedence, talk about degrading?

    Tony DeSimone:
    We are talking about degrading.

    These are just high-level requirements. Let's get through this presentation, in view of our time limit for this WG meeting.

    Tony DeSimone:
    The fundamental requirement: The network needs to support the commanders' intent with respect to what resources are available. Pre-emption: We need to look at this with respect to how it applies to data. The state of network: with respect to precedence and pre-emption. Something that is meaningful to the user needs to be offered.

    Transport services, what the network nodes are implementing is important.

    Precedence and pre-emption needs to be done to support users.

    There is a GIG capabilities document that covers generic switching.

    The Fundamental Requirements slide is an important slide: it lays out the issues.

    Derived goals:
    Turn high-level requirements into goals Some requirements are incomplete

    and inconsistent, that is why derived goals have been done. There are subtleties how you can do pre-emption and precedence in the packet world.

    Ken Carlberg:
    You should consider when you turn this into a draft that you will need a terminology section.

    Tony DeSimone: We need to harmonize the terminology and that is our intent.

    James Polk:
    Is any of this to be turned into an Internet draft?

    Tony DeSimone:
    Yes, at the next meeting.

    Steve Silverman:
    Will the slides be sent to the IETF for IETF participants to view?
    Many in the audience wanted the slides available to the WG before the meeting.

    Tony DeSimone:
    The slides will be made available. Some of the other documents mentioned are subject to "access control".

    Kwok Ho Chan:
    How is the IETF to work on something (e.g. GIG) that is under access control?

    Tony DeSimone:
    There are a large number of documents that are driving the GIG. Some of these documents are classified. We are trying to extract relevant unclassified requirements documents for IETF work.
    In general some material cannot be made public.

    Kwok Ho Chan:
    There will be problems if we do not have access to all the requirements.

    It is up to a specific country to make decisions on what to be made available with respect to requirements. This is an open forum

    Kwok Ho Chan:
    Some material is not open.

    The mapping of what is not open into the requirements we define here will be the responsibility of each individual company or country. The requirements for our work will be openly available.

    Having completed this Agenda item, Kimberly called for An Nguyen to cover the last Agenda item, the NCS presentation

    An Nguyen's short presentation covered the NCS perspective on the new proposed charter for Ieprep.

    An recalled the origins of Ieprep several years ago in the original BOF on Ieprep. The BOF addressed how to get priority service across packet switched networks.

    An stated that NCS is happy with the requirements documents work already

    done by Ieprep during the past few years. The NCS does not oppose DoD work in Ieprep. From the NCS perspective of ETS and GETS, MLPP (of DoD) is deployed in a private network. The NCS does not see any conflict.

    Now after 4 years, we have requirements that will enable us to work on solutions for priority services. Accordingly, we can plan for future services.

    Note: Two current (other) documents are relevant to NCS interests. These are: the QoS NSLP QSPEC document, and the resource management RMD - QOSM document.

    The most important requirements from the list of 14 high level NCS requirements that were stated several years ago by the NCS are: interoperability, priority voice, and authentications.

    ETS (Emergency Telecommunication Service) type solutions will be identified in other WGs, in the future, as they may occur. Future applications of interest to the NCS include: priority data and video.

    General priority system requirements are what we are trying to do.

    Having completed all Agenda items in the allocated time, Kimberly adjourned the WG meeting.


    NCS Perspective on Future Work in IEPREP
    Precedence and Preemption for the GIG Transport Services