RESEND RE: [Ieprep] Another version of a potential IEPREP charter (UNCLASSIFIED)
"Perschau, Stephen CIV NCS NC2" <stephen.perschau@dhs.gov> Fri, 07 July 2006 17:29 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1Fyu95-0004QY-3z; Fri, 07 Jul 2006 13:29:39 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyu94-0004QT-Dk
for ieprep@ietf.org; Fri, 07 Jul 2006 13:29:38 -0400
Received: from pfwhqs1.ncr.disa.mil ([209.22.99.17]
helo=pfwhqs100.ncr.disa.mil)
by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyu94-0001B9-2u
for ieprep@ietf.org; Fri, 07 Jul 2006 13:29:38 -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: RESEND RE: [Ieprep] Another version of a potential IEPREP charter
(UNCLASSIFIED)
Date: Fri, 7 Jul 2006 13:29:37 -0400
Message-ID: <9B4320CC9BC1D847AFFA97F25A422A590C6D09@vanualevu.disanet.disa-u.mil>
in-reply-to: <9B4320CC9BC1D847AFFA97F25A422A590C6D08@vanualevu.disanet.disa-u.mil>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: RESEND RE: [Ieprep] Another version of a potential IEPREP
charter (UNCLASSIFIED)
Thread-Index: Acah53YmJWVpB+JBQwSQQp+nuxSxRAAAahgA
From: "Perschau, Stephen CIV NCS NC2" <stephen.perschau@dhs.gov>
To: "ken carlberg" <carlberg@g11.org.uk>
X-OriginalArrivalTime: 07 Jul 2006 17:29:37.0664 (UTC)
FILETIME=[EBC56800:01C6A1EA]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3971661e40967acfc35f708dd5f33760
Cc: ieprep@ietf.org
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
Classification: UNCLASSIFIED Caveats: NONE Sorry for having to resend this but the text deletions/modifications in Ken's proposed text did not go through as highlighted. Ignore the previous email. Stephen Perschau -----Original Message----- From: Perschau, Stephen CIV NCS NC2 Sent: Friday, July 07, 2006 1:05 PM To: ken carlberg Cc: ieprep@ietf.org Subject: RE: [Ieprep] Another version of a potential IEPREP charter (UNCLASSIFIED) Classification: UNCLASSIFIED Caveats: NONE Essentially accept Ken's proposal with some modifications. Still do not like the text that Ken didn't modify so my suggested changes are provided. Hopefully the strikeouts and additions are visible. This proposed text brings the charter in line with the deliverables and makes it clear that the focus is on MLPP for managed IP networks and public networks where permissible by regulations/law. Stephen Perschau <Text Proposed By Carlberg>--------------------------------------------------------------- ------------------------------ Internet Prioritization and Preparedness (IEPREP) Charter Prioritization involves conveying the importance of communications. Communities of interest have viewed prioritization as one step in facilitating response and recovery operations during emergencies/ disasters, or at times when network resources are stressed possibly due to damage, congestion, denial of service attacks, etc. It is during these types of events that particular sets of users (e.g., authorized users) have a need to obtain the best available service. Either circumstance may involve communications over the Internet or private IP networks/intranets. Natural disasters (e.g., hurricanes, floods, earthquakes) and those created by man (e.g., terrorist attacks, wartime events) may occur at any time. Quick response for response and recovery operations requires immediate access to available telecommunications resources. These resource include not only: conventional telephone, cellular phones, and Internet access via online terminals, IP telephones, and wireless PDAs but also access to available network resources (e.g., bandwidth). Because telecommunications infrastructures are rapidly evolving to Internet-based technology the Internet community needs to consider how its protocols can support prioritized communications in government/military networks. There are different ways to provide prioritization: (1) traffic engineering or schemas that improve the probability of establishing/maintaining communications during times of stress, or (2) a more binary approach of displacing or preempting lower priority communications. <Text Proposed by Carlberg>--------------------------------------------------------------- --------------------------- Delete all text beginning with "The IEPREP WG will address proactive measures...." up to the milestones and insert the following replacement text: <NEW>------------------------------------------------------------------- ----------------------------------------<NEW> The IEPREP WG will address proactive measures to deal with response and recovery efforts from the following two perspectives: 1. A government/military telecommunications network that retains sole administration control 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. While voice traffic was the driving application in the past, preferential treatment needs to be applied to all traffic pertaining to response and recovery operations. This includes real-time (e.g., voice, streaming video, etc.) and non-real-time (e.g., text messaging, SMS, etc.) traffic that will be competing for the same network resources as non response and recovery operations traffic. The WG will document the preferential treatment mechanisms that are appropriate for communications used in response and recovery operations. 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' government/military 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. 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 different security levels, etc. that should be described before mechanisms are proposed. The WG will document the context for implementation solutions. In the IETF, consideration for treatment and security of communications for response and recovery operations stretch across a number of working groups, mostly in the RAI Area, including various working groups involved with voice/video signaling, instant messaging, QoS signaling, etc. The WG will cooperate closely with these groups and with those outside the IETF (e.g., ITU-T Study Groups). To ensure high quality specifications the WG will pursue subject matter expert (e.g., security) for specification review. If there is an existing group that can extend a protocol or mechanism, the IEPREP WG will generate a requirements document for evaluation by the group responsible for the protocol. If there is not an existing group that can extend a protocol or mechanism, the IEPREP WG will prepare requirements and discuss the extension of that protocol/mechanism or protocols/mechanisms within IEPREP. <NEW>------------------------------------------------------------------- --------------------------------------,NEW> The milestones remain as proposed Classification: UNCLASSIFIED Caveats: NONE _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep Classification: UNCLASSIFIED Caveats: NONE _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep
- [Ieprep] Another version of a potential IEPREP ch… King, Kimberly S.
- Re: [Ieprep] Another version of a potential IEPRE… James M. Polk
- RE: [Ieprep] Another version of a potential IEPRE… GOLDMAN, STUART O (STUART)
- Re: [Ieprep] Another version of a potential IEPRE… ken carlberg
- RE: [Ieprep] Another version of a potential IEPRE… Perschau, Stephen CIV NCS NC2
- RESEND RE: [Ieprep] Another version of a potentia… Perschau, Stephen CIV NCS NC2
- Re: RESEND RE: [Ieprep] Another version of a pote… Janet P Gunn