[Ieprep] WG Review: Recharter of Internet Emergency Preparedness (ieprep)

"James M. Polk" <jmpolk@cisco.com> Wed, 01 November 2006 19:54 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMAG-0002GY-8S; Wed, 01 Nov 2006 14:54:20 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMAE-0002GT-U1 for ieprep@ietf.org; Wed, 01 Nov 2006 14:54:18 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfMA9-00053H-V1 for ieprep@ietf.org; Wed, 01 Nov 2006 14:54:18 -0500
Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 01 Nov 2006 11:54:14 -0800
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA1JsDjW015586 for <ieprep@ietf.org>; Wed, 1 Nov 2006 11:54:13 -0800
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kA1Jrsbj023828 for <ieprep@ietf.org>; Wed, 1 Nov 2006 11:54:13 -0800 (PST)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 14:54:11 -0500
Received: from jmpolk-wxp.cisco.com ([10.89.20.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 14:54:10 -0500
Message-Id: <4.3.2.7.2.20061101134639.026a5140@email.cisco.com>
X-Sender: jmpolk@email.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 01 Nov 2006 13:54:09 -0600
To: ieprep@ietf.org
From: "James M. Polk" <jmpolk@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 01 Nov 2006 19:54:10.0921 (UTC) FILETIME=[7FC42590:01C6FDEF]
DKIM-Signature: a=rsa-sha1; q=dns; l=8743; t=1162410853; x=1163274853; c=relaxed/simple; s=sjdkim7002; 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:WG=20Review=3A=20Recharter=20of=20Internet=20Emergency=20Preparedness=0A =20=20(ieprep)=20; X=v=3Dcisco.com=3B=20h=3Do76BrOdtNbyzQZqQdiHGOykUDWE=3D; b=PseldsqC1ah9K+mL2DJrNoGohMxr74Ay74LUCg5QcIBl9YlSFJ2St9GEuCQgByNUOdHZcTts elT5laeXPCu3lKLnipiq6/nCuoPUfSxpqt6y3idF5fRkE8mtLJKrvwhO;
Authentication-Results: sj-dkim-7.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48
Subject: [Ieprep] WG Review: Recharter of Internet Emergency Preparedness (ieprep)
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

WG

I recommend those that are subscribed to the ietf@ieft.org mailer pay 
attention for any negative comments about this recharter, and in fact the 
longevity of this WG as a whole.  Rumors are that *some* want this WG to go 
away very soon.

I believe the discussion about this will NOT be on the WG list, but on the 
ietf@ieft.org mailer (which I recommend you subscribe to if you want to be 
part of any discussions about this WG).

As with all things IETF, few controversial ideas progress without positive 
comments and feedback.

>To: ietf-announce@ietf.org
>From: IESG Secretary <iesg-secretary@ietf.org>
>Date: Wed, 01 Nov 2006 13:59:52 -0500
>Cc: Kimberly King <kimberly.s.king@saic.com>om>, Scott Bradner <sob@harvard.edu>du>,
>         ieprep@ietf.org
>Subject: [Ieprep] WG Review: Recharter of Internet Emergency Preparedness
>         (ieprep)
>
>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).
>
>_______________________________________________
>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