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

"James M. Polk" <jmpolk@cisco.com> Mon, 12 June 2006 19:00 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fprdz-0004Pd-Pz; Mon, 12 Jun 2006 15:00:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fprdy-0004Ow-TW for ieprep@ietf.org; Mon, 12 Jun 2006 15:00:10 -0400
Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fprdy-00082y-BH for ieprep@ietf.org; Mon, 12 Jun 2006 15:00:10 -0400
Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 12 Jun 2006 12:00:09 -0700
X-IronPort-AV: i="4.05,229,1146466800"; d="scan'208"; a="1824175000:sNHT55950388"
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k5CJ09G6027884; Mon, 12 Jun 2006 12:00:09 -0700
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5CJ09cL020245; Mon, 12 Jun 2006 12:00:09 -0700 (PDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Jun 2006 15:00:08 -0400
Received: from jmpolk-wxp.cisco.com ([10.89.16.71]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Jun 2006 15:00:08 -0400
Message-Id: <4.3.2.7.2.20060612135818.040b68b0@email.cisco.com>
X-Sender: jmpolk@email.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 12 Jun 2006 14:00:06 -0500
To: "King, Kimberly S." <KIMBERLY.S.KING@saic.com>, ieprep@ietf.org
From: "James M. Polk" <jmpolk@cisco.com>
Subject: Re: [Ieprep] Another version of a potential IEPREP charter
In-Reply-To: <702ADCB87C5EF340B1D7A597A9DFF1DA01188600@0015-its-exmb02.u s.saic.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-OriginalArrivalTime: 12 Jun 2006 19:00:08.0411 (UTC) FILETIME=[6C6BE2B0:01C68E52]
DKIM-Signature: a=rsa-sha1; q=dns; l=7245; t=1150138809; x=1151002809; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20<jmpolk@cisco.com> |Subject:Re=3A=20[Ieprep]=20Another=20version=20of=20a=20potential=20IEPREP=20cha rter; X=v=3Dcisco.com=3B=20h=3Dle3aD6e3US15oBG3z9RUKejBNXg=3D; b=JtWX3jlzsEtOf7UnkSMHCd4GCVnbrpmry1rXVC5K9M7+UJ3oH0TFph7UOcV/5PNlcN6F6BrC wcjsKhJctj23JGAx+nyGxuKBMAnsjZyJ2gOhacI88cW0qtRQ4tz3Um1k;
Authentication-Results: sj-dkim-7.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26
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

I would add at the bottom that "...we will consider rechartering for new 
work if there is WG consensus to do so, or shut the WG down."

Otherwise, this looks good.

At 12:30 PM 6/12/2006 -0400, King, Kimberly S. wrote:
>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