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
- RE: [Ieprep] (Forwarded) alternate version of rev… King, Kimberly S.
- RE: [Ieprep] (Forwarded) alternate version of rev… Janet P Gunn