Re: [Ieprep] Re-charter?
"Jason Michael Canon" <fiatlux@adelphia.net> Fri, 01 July 2005 20:56 UTC
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21264 for <ieprep-archive@ietf.org>; Fri, 1 Jul 2005 16:56:02 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoSyQ-0003iQ-Qj for ieprep-archive@ietf.org; Fri, 01 Jul 2005 17:22:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoSWr-0000Fx-0U; Fri, 01 Jul 2005 16:54:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoSWm-0008VE-4g; Fri, 01 Jul 2005 16:54:26 -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 QAA21042; Fri, 1 Jul 2005 16:54:21 -0400 (EDT)
Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoSwn-0003cN-P5; Fri, 01 Jul 2005 17:21:18 -0400
Received: from canondownstairs ([68.65.34.212]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050701205407.NYQF19267.mta10.adelphia.net@canondownstairs>; Fri, 1 Jul 2005 16:54:07 -0400
Message-ID: <011401c57e7f$05227da0$6401a8c0@canondownstairs>
From: Jason Michael Canon <fiatlux@adelphia.net>
To: "King, Kimberly S." <KIMBERLY.S.KING@saic.com>, Janet P Gunn <jgunn6@csc.com>
References: <OF162588F5.55F41921-ON85257031.006CE6ED-85257031.006E31C5@csc.com>
Subject: Re: [Ieprep] Re-charter?
Date: Fri, 01 Jul 2005 16:54:05 -0400
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="UTF-8"; reply-type="original"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2527
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA21042
Cc: ieprep-bounces@ietf.org, ieprep@ietf.org, jon.peterson@neustar.biz, sob@harvard.edu
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>
Sender: ieprep-bounces@ietf.org
Errors-To: ieprep-bounces@ietf.org
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82
Content-Transfer-Encoding: quoted-printable
I have a generic, high level question. As a civilian in an emergency situation I call 9-1-1 to report some life threatening situation in my house. While the call is in progress a sufficient number of government officials evoke a GETS/WAS or MOP capability and my call is effectively preempted or degraded to a level that is not tolerable. My question is did a public policy debate result in a Congressional law or FCC Regulation that permits the ITEM to craft enabling technology? If so, a reference to the document would be greatly appreciated. Thanks, Jason ----- Original Message ----- From: "Janet P Gunn" <jgunn6@csc.com> To: "King, Kimberly S." <KIMBERLY.S.KING@saic.com> Cc: <ieprep-bounces@ietf.org>; <jon.peterson@neustar.biz>; <ieprep@ietf.org>; <sob@harvard.edu> Sent: Friday, July 01, 2005 4:01 PM Subject: Re: [Ieprep] Re-charter? > > > > > I have a generic, high level comment. > > If we are extending the charter from “requirements only” to “requirements > and solutions where not covered elsewhere”, I think the solution space > should include solutions for “the evolution of GETS/WPS to IP” as well as > solutions for “the evolution of MLPP to IP”. > > Similarly, the requirements and frameworks that have been previously > produced cover the entire IEPREP scope, both "sort of like MLPP" and "sort > of like GETS". So I think it would be appropriate to have deliverables > such as > "Emergency Threats Analysis for Commercial/Public Networks" > "Requirements for Emergency Preparedness in Commercial/Public Networks" > "Potential Solutions for Commercial/Public Networks" > "Mechanisms to be Used by Commercial/Public Networks" > as well as the ones proposed for "Government/Military Networks". > > I think that would be more useful than "Differences between GETS and MLPP > networks", especially since some of the differences which are significant > in the circuit switched world may be less significant in the packet > switched world. But maybe if I saw an abstract of what was intended for > the document, I would change my mind. > > Janet > > > ---------------------------------------------------------------------------------------- > > This is a PRIVATE message. If you are not the intended recipient, please > delete without copying and kindly advise us by e-mail of the mistake in > delivery. NOTE: Regardless of content, this e-mail shall not operate to > bind CSC to any order or other contract unless pursuant to explicit > written > agreement or government initiative expressly permitting the use of e-mail > for such purpose. > ---------------------------------------------------------------------------------------- > > > > > > "King, Kimberly > S." To: "Ieprep > (ieprep@ietf.org)" <ieprep@ietf.org> > <KIMBERLY.S.KING cc: sob@harvard.edu, > "Jon Peterson \(jon.peterson@neustar.biz\)" > @saic.com> <jon.peterson@neustar.biz> > Sent by: Subject: [Ieprep] > Re-charter? > ieprep-bounces > > > 06/30/2005 10:24 > AM > > > > > > > Scott and I have asked for a 1 hour meeting slot at > the Paris IETF meeting to discuss a possible re-charter > of ieprep. A provisional new charter is included below. > > Kimberly > > > ***************************************** > Draft revision > 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. The IEPREP WG will address proactive and > reactive robustness and recovery from various outages using > three perspectives: > > 1. A commercial (i.e., or public) telecommunications > infrastructure > > 2. A governmental/military telecommunications infrastructure > that may retains sole ownership and administration of its > own 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. > > 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. > > 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. Thus, proactive mechanisms to address would-be > outages are required for these scenarios. > > The IEPREP WG will work on these three perspectives > (commercial, governmental/military, and the combination) and > synergize common mechanisms and requirements into other > groups where possible, while maintaining a separate track of > IEPREP documents for the unique mechanisms and requirements > of each perspectives. > > Now that the initial documents describe the broad problem > space and its salient characteristics, new efforts will > focus on specific requirements and solutions such as those > pertaining to the governmental/military sector. One > 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 be the > basis of more work in this IEPREP WG. Some additional > efforts on the governmental/military track within IEPREP > will 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) 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. Non-real-time applications require measures of QoS and > other 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 telephony > signaling working groups, Protocol for carrying > Authentication for Network Access (pana), 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 WG that can discuss the requirements > for extending their protocol or mechanism, IEPREP will > generate only a requirements document for that group to > discuss. > > If there is not an existing WG that can discuss the > requirements for extending their 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 > > Dec 03 Submit Recommendations I-D to IESG for publication as > a BCP > > 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 > > 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
- [Ieprep] Re-charter? King, Kimberly S.
- Re: [Ieprep] Re-charter? Henning Schulzrinne
- Re: [Ieprep] Re-charter? Dennis Q Berg
- Re: [Ieprep] Re-charter? Janet P Gunn
- Re: [Ieprep] Re-charter?time slot? Janet P Gunn
- Re: [Ieprep] Re-charter? Janet P Gunn
- Re: [Ieprep] Re-charter? Jason Michael Canon
- Re: [Ieprep] Re-charter? Jason Michael Canon
- Re: [Ieprep] Re-charter? Fred Baker
- Re: [Ieprep] Re-charter? Dennis Q Berg
- RE: [Ieprep] Re-charter? Steve Silverman
- Re: [Ieprep] Re-charter? Janet P Gunn
- RE: [Ieprep] Re-charter? Bose, Pratik
- Re: [Ieprep] Re-charter? Dennis Q Berg
- Re: [Ieprep] Re-charter? [Sessions?] James M. Polk
- Re: [Ieprep] Re-charter? [solutions already?] James M. Polk
- RE: [Ieprep] Re-charter? [MLPP limited to private… James M. Polk
- Re: [Ieprep] Re-charter? [IP911 and preemption] James M. Polk
- Re: [Ieprep] Re-charter? James M. Polk
- Re: [Ieprep] Re-charter? [MLPP limited to private… Janet Gunn
- [Ieprep] Re-charter? Dennis Q Berg
- RE: [Ieprep] Re-charter? Ken Carlberg
- RE: [Ieprep] Re-charter? Dennis Q Berg
- RE: [Ieprep] Re-charter? James M. Polk
- RE: [Ieprep] Re-charter? King, Kimberly S.