RESEND RE: [Ieprep] Another version of a potential IEPREP charter (UNCLASSIFIED)

"Perschau, Stephen CIV NCS NC2" <> Fri, 07 July 2006 17:29 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1Fyu95-0004QY-3z; Fri, 07 Jul 2006 13:29:39 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1Fyu94-0004QT-Dk for; Fri, 07 Jul 2006 13:29:38 -0400
Received: from ([] by with esmtp (Exim 4.43) id 1Fyu94-0001B9-2u for; 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: <>
in-reply-to: <>
Thread-Topic: RESEND RE: [Ieprep] Another version of a potential IEPREP charter (UNCLASSIFIED)
Thread-Index: Acah53YmJWVpB+JBQwSQQp+nuxSxRAAAahgA
From: "Perschau, Stephen CIV NCS NC2" <>
To: "ken carlberg" <>
X-OriginalArrivalTime: 07 Jul 2006 17:29:37.0664 (UTC) FILETIME=[EBC56800:01C6A1EA]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3971661e40967acfc35f708dd5f33760
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet Emergency Preparedness Working Group <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

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
Subject: RE: [Ieprep] Another version of a potential IEPREP charter

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

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

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

<Text Proposed by

Delete all text beginning with "The IEPREP WG will address proactive
measures...." up to the milestones and insert the following replacement


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.


The milestones remain as proposed
Classification:  UNCLASSIFIED
Caveats: NONE
Ieprep mailing list
Classification:  UNCLASSIFIED 
Caveats: NONE

Ieprep mailing list