RE: [Ieprep] (Forwarded) alternate version of revised IEPREP charter

Janet P Gunn <jgunn6@csc.com> Mon, 26 June 2006 14:25 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fus26-0002lE-PQ; Mon, 26 Jun 2006 10:25:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fus25-0002iv-Fb for ieprep@ietf.org; Mon, 26 Jun 2006 10:25:45 -0400
Received: from amer-mta07.csc.com ([20.137.52.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fus1y-0004SP-25 for ieprep@ietf.org; Mon, 26 Jun 2006 10:25:45 -0400
Received: from amer-gw09.csc.com (amer-gw09.csc.com [20.6.39.245]) by amer-mta07.csc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id k5QEPbi4007669 for <ieprep@ietf.org>; Mon, 26 Jun 2006 10:25:37 -0400 (EDT)
In-Reply-To: <702ADCB87C5EF340B1D7A597A9DFF1DA01426E9F@0015-its-exmb02.us.saic.com>
Subject: RE: [Ieprep] (Forwarded) alternate version of revised IEPREP charter
To: "King, Kimberly S." <KIMBERLY.S.KING@saic.com>, ieprep@ietf.org
X-Mailer: Lotus Notes 652HF83 November 04, 2004
Message-ID: <OF72215A31.4CC2A8AC-ON85257199.004F23B4-85257199.004F3F2F@csc.com>
From: Janet P Gunn <jgunn6@csc.com>
Date: Mon, 26 Jun 2006 10:25:34 -0400
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 06/26/2006 10:24:33 AM
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: da36eda0a3266ed30a56c496b15b76c7
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 agree.

Janet


--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------



"King, Kimberly S." <KIMBERLY.S.KING@saic.com> wrote on 06/26/2006 09:43:08
AM:

> Hello Martin,
>
> I am pleased that folks are expressing support for the milestones and
> activities presented in the alternate version of the charter as they
> coincide with the version of the charter that I sent out.
>
> The only substantive change of the potentially revised charter (sent out
by
> Janet on behalf of Steve) is a name change of the working group from
IEPREP
> to MTW (MLPP That Works).  I think there is little chance of the IESG
> supporting such a name change.  Thus if it is the work and the activities
> are what is important, then it makes sense to focus on the version that I
> posted on June 12.
>
> Namely:
>
>
> 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).
>
>
>
> -----Original Message-----
> From: ieprep-bounces@ietf.org [mailto:ieprep-bounces@ietf.org] On Behalf
Of
> Dolly, Martin C, ALABS
> Sent: Friday, June 23, 2006 8:36 PM
> To: Janet P Gunn; ieprep@ietf.org
> Cc: Taylor, Carollyn D CIV NCS NC2; stephen.perschau@dhs.gov
> Subject: RE: [Ieprep] (Forwarded) alternate version of revised IEPREP
> charter
>
> Hello,
>
> I support this charter, and being there has not been ay other views, I
> assume you all agree as well. (ass/u/me)
>
> Kimberly: what is your view as chair???
>
>  Peace,
>
> Martin
>
> -----Original Message-----
> From: Janet P Gunn [mailto:jgunn6@csc.com]
> Sent: Tuesday, June 13, 2006 1:37 PM
> To: ieprep@ietf.org
> Cc: Taylor, Carollyn D CIV NCS NC2; stephen.perschau@dhs.gov
> Subject: [Ieprep] (Forwarded) alternate version of revised IEPREP
> charter
>
>
>
>
>
> I have been asked to send this to the IEPREP list on behalf of Carol-Lyn
> Taylor and Stephen Perschau (both of NCS).
>
> Janet
>
>
> ------------------------------------------------------------------------
> ------------------------------------------------------------------------
> --------------------------------
>
> This is a PRIVATE message. If you are not the intended recipient, please
> delete without copying and kindly advise us by e-mail of the mistake in
> delivery. NOTE: Regardless of content, this e-mail shall not operate to
> bind CSC to any order or other contract unless pursuant to explicit
> written
> agreement or government initiative expressly permitting the use of
> e-mail
> for such purpose.
> ------------------------------------------------------------------------
> ------------------------------------------------------------------------
> --------------------------------
>
>
> ----- Forwarded by Janet P Gunn/FED/CSC on 06/13/2006 01:30 PM -----
>
>
> > Sent on behalf of Stephen Perschau:
> >
> > Attached is a version of the proposed draft new charter that I would
> > like to see discussed.  It is different from the one sent by Dr.
> > King.  This version of the proposed draft charter focuses on DoD
> > aspects.  MLPP is not an intrinsic aspect of an ETS although it can
> > be used where permitted.  MLPP is used on a daily basis by DoD in
> > their enterprise network and the charter should reflect that fact.
> > Stephen Perschau
> > *********************************************************************
> > MTW (MLPP That Works) Formally (ieprep) Charter
> >
> > Description of Working Group: Effective telecommunications
> > capabilities in enterprise networks (private commercial or
> > government/military networks) are necessary for normal day-to-day
> > operations. These enterprise capabilities can also be used to
> > facilitate response and recovery operations for emergency events
> > including natural disasters (e.g., hurricanes, floods, earthquakes)
> > and those created by man (e.g., terrorist attacks, combat situations
> > or wartime events).
> >
> > The WG will address proactive measures to deal with emergency events
> > from the following perspectives:
> >
> > 1. A government/military telecommunications network that retains
> > sole administration of its own network resources.
> >
> > 2. A government/military telecommunications infrastructure that
> > combines enterprise network resources and leverages public network
> resources.
> >
> > These new efforts will focus on specific requirements and solutions
> > pertaining to the government/military sector.
> > The following apply:
> > 1. Under certain circumstances, some countries require their
> > 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 government/military
> > networks, requirements for precedence-based capabilities will need
> > to be developed. The Working Group (WG) will document these
> > requirements as they pertain to technologies of interest to IETF.
> >
> > 2.  Some countries 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 limitations arising from
> > differing security levels, etc. that should be described before
> > mechanisms are proposed. The WG will document the context for
> > implementing solutions.  In addition, solutions must be developed
> > when appropriate.
> >
> > 3. While voice was the driving application in the past, preferential
> > treatment will need to be applied to all applications used in
> > response and recovery operations. Preferential treatment must be
> > applied to real-time (e.g., voice) and non-real-time applications
> > (e.g., Text messaging, SMS) that share the same network. The WG will
> > document the preferential treatment mechanisms that are appropriate
> > for any essential communications.
> >
> > In the IETF, considerations for treatment and security of
> > communications for response and recovery operations 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. The WG will cooperate closely with these groups
> > and with those outside of the IETF such as ITU-T study groups.  In
> > addition, the WG 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, the WG 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, the WG will prepare requirements and
> > discuss the extension of that protocol/mechanism or
> > protocols/mechanisms within the WG.
> >
> > Goals and Milestones:
> >
> > Aug 06 Submit an initial I-D of Requirements of Government/Military
> > Networks for Precedence and Preemption
> >
> > 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.
> > Jan 07 Submit 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).
> >
> > Classification:  UNCLASSIFIED
> > Caveats: NONE
> >
> > Classification:  UNCLASSIFIED
> > Caveats: NONE
>
>
> _______________________________________________
> 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
>
> _______________________________________________
> 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