Re: [Ieprep] Proposed Revised Charter

Janet Gunn <jgunn@ix.netcom.com> Wed, 07 September 2005 17:34 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED3oX-0002B2-S1; Wed, 07 Sep 2005 13:34:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED3oW-0002Ak-Mz for ieprep@megatron.ietf.org; Wed, 07 Sep 2005 13:34:24 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04553 for <ieprep@ietf.org>; Wed, 7 Sep 2005 13:34:23 -0400 (EDT)
Received: from smtpauth04.mail.atl.earthlink.net ([209.86.89.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED3rk-0004no-2e for ieprep@ietf.org; Wed, 07 Sep 2005 13:37:44 -0400
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=QU5d2dZNXLS2RuRR9gFK7NTO5f+gGQTovWdzkLrJ7JsGzmRSJKxdhnhH9E4DMXiW; h=Received:Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.42] (helo=elwamui-muscovy.atl.sa.earthlink.net) by smtpauth04.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1ED3oI-0007bc-41; Wed, 07 Sep 2005 13:34:10 -0400
Message-ID: <10418704.1126114449996.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net>
Date: Wed, 07 Sep 2005 13:34:09 -0400
From: Janet Gunn <jgunn@ix.netcom.com>
To: Antonio De Simone <antonio.desimone@jhuapl.edu>, "King,Kimberly S." <KIMBERLY.S.KING@saic.com>
Subject: Re: [Ieprep] Proposed Revised Charter
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Earthlink Zoo Mail 1.0
X-ELNK-Trace: ee238991c8bb1512372ac5f331c56529c275e889330c2f88cb2924e13808fee91baa562a38bb64cb350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.42
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80
Content-Transfer-Encoding: 7bit
Cc: ieprep@ietf.org, "Cole, Robert G." <Robert.Cole@jhuapl.edu>, sob@harvard.edu, jon.peterson@neustar.biz
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Janet Gunn <jgunn@ix.netcom.com>
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>
Sender: ieprep-bounces@ietf.org
Errors-To: ieprep-bounces@ietf.org

I think that both the "old" and "new" versions of 2 are valid statements, but it isn't clear what they have to do with IEPREP.

Nested VPNs need "special treatment" to deal with routing and QoS just for "normal" calls.  They may also need some kind of special treatment for priority over "normal calls" but that isn't included in either version of the text.

Since I am not sure exactly what it is you are TRYING to say, I can't suggest alternate text.

Janet

-----Original Message-----
From: Antonio De Simone <antonio.desimone@jhuapl.edu>
Sent: Sep 7, 2005 1:13 PM
To: "King, Kimberly S." <KIMBERLY.S.KING@saic.com>
Cc: jon.peterson@neustar.biz, "Cole, Robert G." <Robert.Cole@jhuapl.edu>, 
	sob@harvard.edu, ieprep@ietf.org
Subject: Re: [Ieprep] Proposed Revised Charter

King, Kimberly S. wrote:

>
> Below is an updated proposed charter for WG review.
>

suggest a rewrite of these two paragraphs
 
<<<<<<<<<<<<
2. Nested VPNs require special considerations for routing and QoS if
nodes in the path that make these decisions generally have limited
information.
 >>>>>>>>>>>
2. VPNs in the manner of IPSec--point-to-point tunnels that encrypt payload
and header information--require special consideration for routing and QoS
because some nodes on the path that make forwarding and scheduling
decisions will have limited information.  Nested VPNs (tunnels in tunnels)
or concatenated VPNs (tunnels terminated at a gateway node) VPNs both need
to be considered.
 
<<<<<<<<<<<<
4. Considering robustness of non-real-time applications with
preferential treatments, as voice will not be the only application used
by IEPREP.
 >>>>>>>>>
4. 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.
 
I think we should also include a November goal of submitting an I-D on
DoD requirements for precedence. Is that the same as your Feb 06 item?


>
> ---
>
> Internet Emergency Preparedness (ieprep) Charter 
>
>
> Description of Working Group: 
>
> Effective telecommunications capabilities are imperative to facilitate 
> immediate recovery operations for serious disaster 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 usable 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 public 
> 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.
>
>
> 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. A governmental/military or enterprise 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. This 
> scenario may be subject to local policies, laws, and regulations. 
> Potential disasters for governmental/military  infrastructures can 
> extend beyond what might be experienced by the commercial/public sector 
> and can be anticipated to some degree.
>
>
> Proactive mechanisms to address would-be outages are required for each 
> of these cases. 
>
>
> Now that the initial documents describe the broad problem space and its 
> salient characteristics have been competed, new efforts will  focus on 
> specific requirements and solutions such as those  pertaining to the 
> governmental/military sector. For example, a document exists in the 
> Transport Area working group of interest to IEPREP that could satisfy a 
> governmental framework/BCP is draft-ietf-tsvwg-mlpp-that-works-XX. This 
> document will progress to completion in that WG, yet may be the basis of 
> more work in this IEPREP WG. Some additional efforts on the 
> governmental/military track within IEPREP could focus on this TSVWG 
> document, analyze gaps, and provide input where needed. 
>
>
> The following are four specific examples that can satisfy  the interests 
> of governmental/military (and potentially, 
> commercial/public/enterprise) emergency communications: 
>
>
> 1. Conveying information about the priority of specific  flows (or 
> sessions) that originate in a VoIP environment.  This could include a 
> requirements effort to describe  extensions to NSIS or RSVP. 
> Requirements for NSIS would be forwarded to the NSIS working group. 
> Requirements for RSVP could be forwarded to tsvwg or worked on in 
> IEPREP. 
>
>
> 2. Nested VPNs require special considerations for routing and QoS if 
> nodes in the path that make these decisions generally have limited 
> information.  
>
>
> 3. Some countries require civil networks to preempt sessions under state 
> circumstances, and preemption is considered an  absolute requirement in 
> governmental networks in most countries. Unless implementation of these 
> requirements can  be objectively shown to threaten network health (via 
> simulation or in operations), then the requirement needs to be 
> considered by IEPREP and specific solutions must be developed. 
>
>
> 4. Considering robustness of non-real-time applications with 
> preferential treatments, as voice will not be the only application used 
> by IEPREP. 
>
>
> In the IETF, considerations for treatment and security of emergency 
> communications stretch across a number of Areas and Working Groups, 
> notably including the various voice/video  signaling working groups, 
> instant messaging, and the open Transport Area for path coupled 
> signaling and various operational groups. IEPREP will cooperate closely 
> with these groups and with those outside of the IETF such as various 
> ITU-T study groups.  
>
>
> 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 Submit Requirements I-D to IESG for publication as an 
> Informational RFC 
>
> Done Submit Framework I-D to IESG for publication as an  Informational 
> RFC 
>
> Oct 05 Submit an initial I-D of Emergency Threats Analysis  of 
> Government/Military Networks 
>
> Dec 05 Submit an initial I-D of Differences between GETS and  MLPP 
> Networks 
>
> Feb 06 Submit an initial I-D of Requirements of  Government/Military 
> Networks 
>
> Mar 06 Submit an initial I-D of Considerations for potential  solutions 
> of Government/Military Networks 
>
> Apr 06 Submit an initial I-D of Mechanisms to be used by 
> Government/Military Networks 
>
> Oct 05 Submit final I-D of Emergency Threats Analysis of 
> Government/Military Networks to IESG as Informational  RFC
>
> Feb 06 Submit final I-D of Requirements of  Government/Military Networks 
> to IESG as Informational RFC 
>
> Apr 06 Submit final I-D of Mechanisms to be used by  Government/Military 
> Networks to IESG as BCP RFC 
>
> Dec 06 Submit Recommendations I-D for commercial telecommunications 
> infrastructure to IESG for publication as  a BCP 
>
> 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 mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep




_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep