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

"King, Kimberly S." <KIMBERLY.S.KING@saic.com> Mon, 26 June 2006 13:43 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FurNJ-0000LN-8N; Mon, 26 Jun 2006 09:43:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FurNH-0000LD-9Z for ieprep@ietf.org; Mon, 26 Jun 2006 09:43:35 -0400
Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FurNG-0000tm-Oe for ieprep@ietf.org; Mon, 26 Jun 2006 09:43:35 -0400
Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Mon, 26 Jun 2006 09:43:24 -0400
Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006062609432127269 ; Mon, 26 Jun 2006 09:43:22 -0400
Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id <NACVK0TA>; Mon, 26 Jun 2006 09:43:21 -0400
Message-Id: <702ADCB87C5EF340B1D7A597A9DFF1DA01426E9F@0015-its-exmb02.us.saic.com>
From: "King, Kimberly S." <KIMBERLY.S.KING@saic.com>
To: "Dolly, Martin C, ALABS" <mdolly@att.com>, Janet P Gunn <jgunn6@csc.com>, ieprep@ietf.org
Subject: RE: [Ieprep] (Forwarded) alternate version of revised IEPREP char ter
Date: Mon, 26 Jun 2006 09:43:08 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 509eeaf340e89c687918a6101c6def35
Cc: "Taylor, Carollyn D CIV NCS NC2" <carol-lyn.taylor@dhs.gov>, stephen.perschau@dhs.gov
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

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