Re: [Ieprep] Another version of a potential IEPREP charter
ken carlberg <carlberg@g11.org.uk> Thu, 06 July 2006 17:10 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyXMu-0002a9-Dc; Thu, 06 Jul 2006 13:10:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyXMt-0002Zz-FI for ieprep@ietf.org; Thu, 06 Jul 2006 13:10:23 -0400
Received: from hermes.hosts.co.uk ([212.84.175.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyXMs-0005iz-SI for ieprep@ietf.org; Thu, 06 Jul 2006 13:10:23 -0400
Received: from [69.138.71.89] (helo=[192.168.1.2]) by hermes.hosts.co.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from <carlberg@g11.org.uk>) id 1FyXMX-0005db-Gm; Thu, 06 Jul 2006 18:10:04 +0100
In-Reply-To: <702ADCB87C5EF340B1D7A597A9DFF1DA01188600@0015-its-exmb02.us.saic.com>
References: <702ADCB87C5EF340B1D7A597A9DFF1DA01188600@0015-its-exmb02.us.saic.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <3E779451-D7B3-47B6-8162-8B0719E8255A@g11.org.uk>
Content-Transfer-Encoding: 7bit
From: ken carlberg <carlberg@g11.org.uk>
Subject: Re: [Ieprep] Another version of a potential IEPREP charter
Date: Thu, 06 Jul 2006 13:10:11 -0400
To: "King, Kimberly S." <KIMBERLY.S.KING@saic.com>
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: -4.4 (----)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53
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
On Jun 12, 2006, at 12:30 PM, King, Kimberly S. wrote:
> We were asked to tighten up the potential new charter. Here is a
> start.
> Comments?
A while back there was a suggestion to change the name of the group
to a name that included MLPP because it seemed that the new
milestones moved away to some degree from the original "emergency"
motivation of the group. It was felt that such a move would not be
accepted by the IESG, so I'd like to make an attempt to find some
middle ground in recognizing the evolution of the group.
below are some suggested changes in both the charter name and in the
first couple of paragraphs of the previously suggested new charter (I
left the rest of the charter intact). Note that the "new" and "old"
sections are marked with "< >" tags).
While there is precedent in changing WG names, I've been told that it
can be a big administrative hassle -- especially with respect to
retaining/associating previous archived information. So, we would be
bound to the same IEPREP acronym.
Finally, you'll notice that the main changes I have suggested is an
emphasis on prioritization (which has always been a foundation of
this group) and de-emphasizing the word "emergency".
comments?
-ken
=====================================
<NEW>
Internet Prioritization and Preparedness (IEPREP) Charter
</new>
<old>
Internet Emergency Preparedness (ieprep) Charter
</old>
<NEW>----------------------------------
Prioritization involves conveying the importance of communications.
Communities of interest have viewed prioritization as one step in
facilitating immediate recovery operations during emergencies/
disasters, or in other occasions when resources are at a minimum and
particular sets of users (e.g., first responders) have a need to
obtain the best available service. Either circumstance may involves
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 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 prioritized
communications.
Actions taken upon prioritized communications vary per interested
party. On one hand, traffic engineering or schemas to improve the
probability of establishing/maintaining communications during times
of distress may prove sufficient. Other groups may have an interest
in a more binary approach of displacing or preempting lower priority
communications.
</new>----------------------------------
<OLD>------------------------------------------------------
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.
</old>-----------------------------------------------------
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).
_______________________________________________
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