RE: [Ieprep] Re-charter?

"Bose, Pratik" <pratik.bose@lmco.com> Tue, 05 July 2005 13: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 JAA18527 for <ieprep-archive@ietf.org>; Tue, 5 Jul 2005 09:26:23 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpnsB-0006fQ-5i for ieprep-archive@ietf.org; Tue, 05 Jul 2005 09:54:03 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpnFc-0004Im-R4; Tue, 05 Jul 2005 09:14:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpnFa-0004HM-DR for ieprep@megatron.ietf.org; Tue, 05 Jul 2005 09:14:10 -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 JAA11609 for <ieprep@ietf.org>; Tue, 5 Jul 2005 09:14:07 -0400 (EDT)
Received: from mailgw3a.lmco.com ([192.35.35.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpngG-0001i0-95 for ieprep@ietf.org; Tue, 05 Jul 2005 09:41:48 -0400
Received: from emss09g01.ems.lmco.com (relay6.ems.lmco.com [166.17.13.59]) by mailgw3a.lmco.com (8.12.10/8.12.10) with ESMTP id j65DDvG6016471; Tue, 5 Jul 2005 09:13:57 -0400 (EDT)
Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1X6 #30875) id <0IJ500F01OR9KH@lmco.com>; Tue, 05 Jul 2005 09:13:57 -0400 (EDT)
Received: from EMSS09I00.us.lmco.com ([158.183.26.31]) by lmco.com (PMDF V6.1-1X6 #30875) with ESMTP id <0IJ500BEQOR98O@lmco.com>; Tue, 05 Jul 2005 09:13:57 -0400 (EDT)
Received: from EMSS04M14.us.lmco.com ([162.16.20.50]) by EMSS09I00.us.lmco.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 05 Jul 2005 09:13:57 -0400
Date: Tue, 05 Jul 2005 09:13:56 -0400
From: "Bose, Pratik" <pratik.bose@lmco.com>
Subject: RE: [Ieprep] Re-charter?
To: "King, Kimberly S." <KIMBERLY.S.KING@saic.com>, ieprep@ietf.org
Message-id: <37B6F612D86CA143B5F965E9EE8BD7AA0C0DFF98@emss04m14.us.lmco.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Thread-Topic: [Ieprep] Re-charter?
Thread-Index: AcV9gCHRRBY9TvpDT0Cgz/evNr6ddgD4jiEw
content-class: urn:content-classes:message
X-OriginalArrivalTime: 05 Jul 2005 13:13:57.0255 (UTC) FILETIME=[66928170:01C58163]
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44
Content-Transfer-Encoding: 7bit
Cc: sob@harvard.edu, jon.peterson@neustar.biz
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.8 (/)
X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e
Content-Transfer-Encoding: 7bit

Hi, 

One important addition to the list of specific examples that comes to
mind is: 

Extensions to Differentiated Services for a secure-authenticated
environment: This category can include authentication for differentiated
services, providing prioritized treatment to elastic data, BCP for
DiffServ in nested VPNs and others.  

Thanks, 

Pratik

-----Original Message-----
From: ieprep-bounces@ietf.org [mailto:ieprep-bounces@ietf.org] On Behalf
Of King, Kimberly S.
Sent: Thursday, June 30, 2005 10:24 AM
To: Ieprep (ieprep@ietf.org)
Cc: sob@harvard.edu; Jon Peterson (jon.peterson@neustar.biz)
Subject: [Ieprep] Re-charter?


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

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