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, 6 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