RE: [Ieprep] Another version of a potential IEPREP charter (UNCLASSIFIED)
"Perschau, Stephen CIV NCS NC2" <stephen.perschau@dhs.gov> Fri, 07 July 2006 17:04 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1Fytkz-0005kN-6z; Fri, 07 Jul 2006 13:04:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43) id 1Fytkx-0005kI-BH
for ieprep@ietf.org; Fri, 07 Jul 2006 13:04:43 -0400
Received: from ionians.ncr.disa.mil ([164.117.82.23])
by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fytkw-0008Ce-Op
for ieprep@ietf.org; Fri, 07 Jul 2006 13:04:43 -0400
Received: from vanualevu.disanet.disa-u.mil ([164.117.144.226]) by
ionians.ncr.disa.mil with Microsoft SMTPSVC(6.0.3790.1830);
Fri, 7 Jul 2006 13:04:42 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Ieprep] Another version of a potential IEPREP charter
(UNCLASSIFIED)
Date: Fri, 7 Jul 2006 13:04:42 -0400
Message-ID: <9B4320CC9BC1D847AFFA97F25A422A590C6D08@vanualevu.disanet.disa-u.mil>
in-reply-to: <3E779451-D7B3-47B6-8162-8B0719E8255A@g11.org.uk>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Ieprep] Another version of a potential IEPREP charter
(UNCLASSIFIED)
Thread-Index: AcahHxmrev5fFCzZTGOEtxjKjLittQAxihtA
From: "Perschau, Stephen CIV NCS NC2" <stephen.perschau@dhs.gov>
To: "ken carlberg" <carlberg@g11.org.uk>
X-OriginalArrivalTime: 07 Jul 2006 17:04:42.0559 (UTC)
FILETIME=[709E7CF0:01C6A1E7]
X-Spam-Score: 1.3 (+)
X-Scan-Signature: 56904003e9d74831849863e83b1962ec
Content-Type: text/plain;
charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
X-Content-Filtered-By: Mailman/MimeDel 2.1.5
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 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 immediate 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 in other occasions when resources are at a minimum and particular sets of users (e.g., first responders 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 any available telecommunications resources capabilities at hand. These resources capabilities 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 the commercial telecommunications infrastructure is rapidly evolving to Internet-based technology . Therefore, the Internet community needs to consider how its protocols can best support prioritized communications in government/military networks. Actions taken upon prioritized communications vary per interested party. There are different ways to provide prioritization (1) On one hand, traffic engineering or schemas to that improve the probability of establishing/maintaining communications during times of stress, (2) distress may prove sufficient. Other groups may have an interest in 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 replcaement 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> 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