RE: [Ieprep] Another version of a potential IEPREP charter

"GOLDMAN, STUART O \(STUART\)" <sgoldman@lucent.com> Sun, 18 June 2006 00:41 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrlLg-00014p-8o; Sat, 17 Jun 2006 20:41:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrlLe-00014k-FI for ieprep@ietf.org; Sat, 17 Jun 2006 20:41:06 -0400
Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrlLd-0002zt-VP for ieprep@ietf.org; Sat, 17 Jun 2006 20:41:06 -0400
Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.6/IER-o) with ESMTP id k5I0f3ho028056; Sat, 17 Jun 2006 19:41:03 -0500 (CDT)
Received: from ILEXC1U01.ndc.lucent.com ([135.3.39.3]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 17 Jun 2006 19:41:02 -0500
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Ieprep] Another version of a potential IEPREP charter
Date: Sat, 17 Jun 2006 19:41:01 -0500
Message-ID: <7A5EF92F6D86BD419418FFBD69E882B654D124@ILEXC1U01.ndc.lucent.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Ieprep] Another version of a potential IEPREP charter
Thread-Index: AcaOPbBA39jgZ6UgR1WELGL7/BzMigEMUdGQ
From: "GOLDMAN, STUART O (STUART)" <sgoldman@lucent.com>
To: "King, Kimberly S." <KIMBERLY.S.KING@saic.com>, ieprep@ietf.org
X-OriginalArrivalTime: 18 Jun 2006 00:41:02.0932 (UTC) FILETIME=[E054D940:01C6926F]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d
Cc:
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet Emergency Preparedness Working Group <ieprep.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ieprep@ietf.org>
List-Help: <mailto:ieprep-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=subscribe>
Errors-To: ieprep-bounces@ietf.org

Kimberly,

Kimberly,

Given the vital importance of emergency communications during disasters
as described below, it certainly seems that the IEPREP group is still
needed. I have no improvements to the draft charter you have proposed.

Stuart Goldman
Lucent Technologies
sgoldman@lucent.com
602 493 8438


-----Original Message-----
From: King, Kimberly S. [mailto:KIMBERLY.S.KING@saic.com] 
Sent: Monday, June 12, 2006 9:30 AM
To: ieprep@ietf.org
Subject: [Ieprep] Another version of a potential IEPREP charter

We were asked to tighten up the potential new charter.  Here is a start.
Comments?

________________________

 

 

 

Internet Emergency Preparedness (ieprep) Charter

 

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 user'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 countries' 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.  

 

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 

 

Aug 06 Submit an initial I-D of Requirements of Government/Military
Networks
for Precedence and Preemption

 

Aug 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

 

Sept 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.

 

Nov 06 Submit final I-D of Requirements of Government/Military Networks
for
Precedence and Preemption to IESG for publication as an Informational
RFC

 

NOV 06 Submit final I-D of ETS Terminology to IESG for publication as an
Informational RFC.

 

Jan 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.

 

Feb 07 Submit an initial I-D of Mechanisms for Precedence and Preemption
to
be used by Government/Military Networks

 

Apr 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

 

Apr 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).

 

 

 

_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep

_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep