[Ieprep] Re-charter?

"King, Kimberly S." <KIMBERLY.S.KING@saic.com> Thu, 30 June 2005 14:26 UTC

Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18019 for <ieprep-archive@ietf.org>; Thu, 30 Jun 2005 10:26:47 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do0Pv-00082W-VT for ieprep-archive@ietf.org; Thu, 30 Jun 2005 10:53:28 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnzyJ-0006e8-Id; Thu, 30 Jun 2005 10:24:55 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnzyH-0006b1-TK for ieprep@megatron.ietf.org; Thu, 30 Jun 2005 10:24:53 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17895 for <ieprep@ietf.org>; Thu, 30 Jun 2005 10:24:51 -0400 (EDT)
Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do0O2-0007xF-W6 for ieprep@ietf.org; Thu, 30 Jun 2005 10:51:32 -0400
Received: from [149.8.64.21] by mclmx.mail.saic.com; Thu, 30 Jun 2005 10:24:29 -0400
Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2005063010242918055 ; Thu, 30 Jun 2005 10:24:29 -0400
Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2657.72) id <N84V1053>; Thu, 30 Jun 2005 10:24:28 -0400
Message-Id: <D24D16A6707B0A4B9EF084299CE99B3922A82DF3@mcl-its-exs02.mail.saic.com>
From: "King, Kimberly S." <KIMBERLY.S.KING@saic.com>
To: "Ieprep (ieprep@ietf.org)" <ieprep@ietf.org>
Date: Thu, 30 Jun 2005 10:24:28 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 2d1100b36d83fed07afbc292d8848e10
Content-Type: text/plain
X-Content-Filtered-By: Mailman/MimeDel 2.1.5
Cc: sob@harvard.edu, "Jon Peterson (jon.peterson@neustar.biz)" <jon.peterson@neustar.biz>
Subject: [Ieprep] Re-charter?
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>
Sender: ieprep-bounces@ietf.org
Errors-To: ieprep-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610

Scott and I have asked for a 1 hour meeting slot at 
the Paris IETF meeting to discuss a possible re-charter 
of ieprep.  A provisional new charter is included below.

Kimberly


*****************************************
Draft revision
Internet Emergency Preparedness (ieprep) Charter   

Description of Working Group:

Effective telecommunications capabilities are imperative to 
facilitate immediate recovery operations for serious 
disaster 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 usable 
in normal command and control operations of military 
services, which often have timeliness requirements even in 
peacetime.  The IEPREP WG will address proactive and 
reactive robustness and recovery from various outages using 
three perspectives:

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

2. A governmental/military telecommunications infrastructure 
that may retains sole ownership and administration of its 
own resources

3. A governmental/military telecommunications infrastructure 
that combines private resources and leverages public 
infrastructure.  This scenario may be subject to local 
policies, laws, and regulations. 

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.

Potential disasters for governmental/military 
infrastructures can extend beyond what might be experienced 
by the commercial/public sector and can be anticipated to 
some degree.  Thus, proactive mechanisms to address would-be 
outages are required for these scenarios.

The IEPREP WG will work on these three perspectives 
(commercial, governmental/military, and the combination) and 
synergize common mechanisms and requirements into other 
groups where possible, while maintaining a separate track of 
IEPREP documents for the unique mechanisms and requirements 
of each perspectives. 

Now that the initial documents describe the broad problem 
space and its salient characteristics, new efforts will 
focus on specific requirements and solutions such as those 
pertaining to the governmental/military sector.  One 
document exists in the Transport Area working group of 
interest to IEPREP that could satisfy a governmental 
framework/BCP is draft-ietf-tsvwg-mlpp-that-works-XX.  This 
document will progress to completion in that WG, yet be the 
basis of more work in this IEPREP WG.  Some additional 
efforts on the governmental/military track within IEPREP 
will focus on this TSVWG document, analyze gaps, and provide 
input where needed.

The following are four specific examples that can satisfy 
the interests of governmental/military (and potentially, 
commercial/public) emergency communications:

1. Conveying information about the priority of specific 
flows (or sessions) that originate in a VoIP environment.  
This could include a requirements effort to describe 
extensions to NSIS or RSVP. Requirements for NSIS would be 
forwarded to the NSIS working group. Requirements for RSVP 
could be forwarded to tsvwg or worked on in IEPREP.

2. Nested VPNs require special considerations for routing 
and QoS if nodes in the path that make these decisions 
generally have limited information.  

3. Some countries require civil networks to preempt sessions 
under state circumstances, and preemption is considered an 
absolute requirement in governmental networks in most 
countries. Unless implementation of these requirements can 
be objectively shown to threaten network health (via 
simulation or in operations), then the requirement needs to 
be considered by IEPREP and specific solutions must be 
developed.

4. Non-real-time applications require measures of QoS and 
other preferential treatments, as voice will not be the only 
application used by IEPREP.

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, Protocol for carrying 
Authentication for Network Access (pana), the open Transport 
Area for path-coupled signaling and various operational 
groups. IEPREP will cooperate closely with these groups and 
with those outside of the IETF such as various ITU-T study 
groups.


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.


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

Oct 05 Submit an initial I-D of Emergency Threats Analysis 
of Government/Military Networks

Dec 05 Submit an initial I-D of Differences between GETS and 
MLPP Networks

Feb 06 Submit an initial I-D of Requirements of 
Government/Military Networks

Mar 06 Submit an initial I-D of Considerations for potential 
solutions of Government/Military Networks

Apr 06 Submit an initial I-D of Mechanisms to be used by 
       Government/Military Networks

Oct 05 Submit final I-D of Emergency Threats Analysis of 
       Government/Military Networks to IESG as Informational 
RFC

Feb 06 Submit final I-D of Requirements of 
Government/Military Networks to IESG as Informational RFC

Apr 06 Submit final I-D of Mechanisms to be used by 
       Government/Military Networks to IESG as BCP RFC

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