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