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

"Dolly, Martin C, ALABS" <mdolly@att.com> Sat, 24 June 2006 00:36 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftw8A-0001IX-EZ; Fri, 23 Jun 2006 20:36:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftw89-0001F0-Mo for ieprep@ietf.org; Fri, 23 Jun 2006 20:36:09 -0400
Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ftw89-0003BW-6X for ieprep@ietf.org; Fri, 23 Jun 2006 20:36:09 -0400
X-VirusChecked: Checked
X-Env-Sender: mdolly@att.com
X-Msg-Ref: server-11.tower-120.messagelabs.com!1151109367!12890326!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 30019 invoked from network); 24 Jun 2006 00:36:07 -0000
Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-11.tower-120.messagelabs.com with SMTP; 24 Jun 2006 00:36:07 -0000
Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.12) by attrh3i.attrh.att.com (7.2.052) id 4479CA7F0033EF37; Fri, 23 Jun 2006 20:36:07 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Ieprep] (Forwarded) alternate version of revised IEPREP charter
Date: Fri, 23 Jun 2006 19:36:06 -0500
Message-ID: <28F05913385EAC43AF019413F674A0170DE0C90D@OCCLUST04EVS1.ugd.att.com>
In-Reply-To: <OF58647744.1A6F86EA-ON8525718C.006029E1-8525718C.0060D08E@csc.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Ieprep] (Forwarded) alternate version of revised IEPREP charter
Thread-Index: AcaPEf1vJ3bahjRQRKOl2/4d7g0FlAIE41Ow
X-Message-Flag: Follow up
From: "Dolly, Martin C, ALABS" <mdolly@att.com>
To: "Janet P Gunn" <jgunn6@csc.com>, <ieprep@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d
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,

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