Re: Re-charter?

Sorry, I meant GETS/WPS and MLPP.

----- Original Message ----- 
From: "Jason Michael Canon" <[email protected]>
To: "King, Kimberly S." <[email protected]>; "Janet P Gunn" 
<[email protected]>
Cc: <[email protected]>; <[email protected]>; 
<[email protected]>; <[email protected]>
Sent: Friday, July 01, 2005 4:54 PM
Subject: Re: [Ieprep] Re-charter?


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" <[email protected]>
To: "King, Kimberly S." <[email protected]>
Cc: <[email protected]>; <[email protected]>;
<[email protected]>; <[email protected]>
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 
> ([email protected])" <[email protected]>
>                      <KIMBERLY.S.KING         cc:      [email protected], 
> "Jon Peterson \([email protected]\)"
>                      @saic.com>               <[email protected]>
>                      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
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ieprep
>


--------------------------------------------------------------------------------


> _______________________________________________
> Ieprep mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ieprep
>


_______________________________________________
Ieprep mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ieprep