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

["James M. Polk" <[e-mail]>]

WG

I recommend those that are subscribed to the [e-mail] 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 
[e-mail] 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: [e-mail]
>From: IESG Secretary <[e-mail]>
>Date: Wed, 01 Nov 2006 13:59:52 -0500
>Cc: Kimberly King <[e-mail]>, Scott Bradner <[e-mail]>,
>         [e-mail]
>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 ([e-mail]) by November 7th.
>
>+++
>
>Internet Emergency Preparedness (ieprep)
>=========================================
>
>Current Status: Active Working Group
>
>Chair(s):
>Scott Bradner <[e-mail]>
>Kimberly King <[e-mail]>
>
>Real-time Applications and Infrastructure Area Director(s):
>Jon Peterson <[e-mail]>
>Cullen Jennings <[e-mail]>
>
>Real-time Applications and Infrastructure Area Advisor:
>Jon Peterson <[e-mail]>
>
>Mailing Lists:
>General Discussion: [e-mail]
>To Subscribe: [e-mail]
>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
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/ieprep

_______________________________________________
Ieprep mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ieprep