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