WG Review: Recharter of Internet Emergency Preparedness (ieprep)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



A modified charter has been submitted for the Internet Emergency 
Preparedness (ieprep) working group in the Real-time Applications and
Infrastructure Area of the IETF. The IESG has not made any 
determination as yet. The modified charter is provided below for 
informational purposes only. Please send your comments to the IESG 
mailing list (iesg@ietf.org) by November 7th.

+++

Internet Emergency Preparedness (ieprep)
=========================================

Current Status: Active Working Group

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

Real-time Applications and Infrastructure Area Director(s):
Jon Peterson <jon.peterson@neustar.biz>
Cullen Jennings <fluffy@cisco.com>

Real-time Applications and Infrastructure 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 emergency events including
natural disasters (e.g., hurricanes, floods,
earthquakes) and those created by man (e.g., terrorist attacks, combat
situations or wartime events). In addition, related capabilities should be
operative in normal command and control operations of military services,
which often have timeliness requirements even in peacetime.

Disasters can happen any time, any place, unexpectedly. Quick response
for recovery operations requires immediate access to any
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.

The IEPREP WG will address proactive measures to congestion and recovery
from various outages using three perspectives:

1. A commercial (i.e., or public) telecommunications infrastructure

2. An enterprise or governmental/military telecommunications
infrastructure that retains sole administration of its own network
resources

3. A governmental/military telecommunications infrastructure that
combines private resources and leverages public infrastructure. 

Now that the initial documents describing the broad problem space and its
salient characteristics have been completed, new efforts will focus on
specific requirements and solutions, such as those pertaining to the
governmental/military sector. The following are specific examples that can
satisfy the interests of governmental/military (and potentially,
commercial/public/enterprise) emergency communications: 

1. Under emergency circumstances, some countries require civil networks
to distinguish sessions based on the userA-s indication of precedence.
The network can use the precedence information to give priority to some
sessions over others, up to and including preemption of lower-precedence
sessions. In many countriesA- governmental networks, the capabilities
needed to support precedence-based preferential treatment are requirements
on the equipment and services used to build those networks.
As Internet-based technology continues to expand into civil and government
networks, requirements for precedence-based capabilities will need to be
developed. IEPREP will document these requirements as they pertain to
technologies of interest to IETF.

2. Specific countries may have additional considerations that define the
context in which they implement session precedence and preemption. For
example, network ownership constraints (which may differ from commercial
deployments), communities of interest including dial-plan considerations,
encryption assumptions and any limitations arising from differing security
levels, etc. that should be described before mechanisms can be proposed.
IEPREP should document the context for implementing solutions. In
addition, specific solutions must be developed when appropriate.

3. While voice was the driving application for IEPREP in the past,
preferential treatments will need to be applied to all applications
essential to emergency communications. Preferential treatment must address
robustness of both voice and non-real-time applications that share the
same infrastructure. The IEPREP WG should document the preferential
treatment mechanisms that are appropriate for any essential
communications.

In the IETF, considerations for treatment and security of emergency
communications stretch across a number of working groups, mostly in the
RAI Area, notably including the various voice/video signaling working
groups, instant messaging, and QoS signaling. IEPREP will cooperate
closely with these groups and with those outside of the IETF such as
various ITU-T study groups. In addition, IEPREP will pursue subject matter
experts (e.g., security) for specification review if such expertise does
not exist within the working group in order to ensure continued high
quality specifications.

If there is an existing group that can extend a protocol or mechanism,
IEPREP will generate only a requirements document for those groups to
evaluate. If there is not an existing group that can extend a protocol or
mechanism, IEPREP will prepare requirements and discuss the extension of
that protocol/mechanism or protocols/mechanisms within IEPREP. Before this
working group undertakes any new protocol development, a recharter is
required.

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 Produce an
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 06 Submit an initial I-D of Requirements of Government/Military
     Networks for Precedence and Preemption Dec 06 Submit an initial I-D
of ETS Terminology. This document should
     define ieprep related terms (e.g., ETS, GETS, MLPP) and explain their

     relationships and how they have been used in existing RFCs Dec 06
Submit an initial I-D of Deployment Considerations of Precedence
     and Preemption on Government/Military Networks. This document should
     clarify the context that Government/Military requirements must
operate.
Mar 07 Submit final I-D of Requirements of Government/Military Networks
     for Precedence and Preemption to IESG for publication as an
     Informational RFC
Mar 07 Submit final I-D of ETS Terminology to IESG for publication as an
     Informational RFC.
Jul 07 Submit an final I-D of Deployment Considerations of Precedence
     and Preemption on Government/Military Networks to IESG for
publication
     as an Informational RFC.
Aug 07 Submit an initial I-D of Mechanisms for Precedence and Preemption
     to be used by Government/Military Networks Sep 07 Submit final I-D of
Mechanisms for Precedence and Preemption to
     be used by Government/Military Networks to IESG for publication as a
BCP Dec 07 The working group will discuss re-chartering if additional
     efforts are agreed upon by the WG (for example, work items related to

     protocols outside existing WGs).

_______________________________________________

IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce

[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux