Re: [Ieprep] Re-charter?

Dennis Q Berg <dberg3@csc.com> Fri, 01 July 2005 21:44 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 RAA26116 for <ieprep-archive@ietf.org>; Fri, 1 Jul 2005 17:44:53 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoTji-00010e-FZ for ieprep-archive@ietf.org; Fri, 01 Jul 2005 18:11:50 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoTGY-00015d-2P; Fri, 01 Jul 2005 17:41:42 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoTGV-0000uo-VL; Fri, 01 Jul 2005 17:41:40 -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 RAA25842; Fri, 1 Jul 2005 17:41:36 -0400 (EDT)
Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoTgY-0000fN-5Y; Fri, 01 Jul 2005 18:08:34 -0400
Received: from amer-gw09.csc.com (amer-gw09.csc.com [20.6.39.245]) by amer-mta02.csc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j61LfZDs018276; Fri, 1 Jul 2005 17:41:35 -0400 (EDT)
Subject: Re: [Ieprep] Re-charter?
To: Jason Michael Canon <fiatlux@adelphia.net>
X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002
Message-ID: <OF2E8886A3.9411CD69-ON85257031.0075FFA5-85257031.0077378E@csc.com>
From: Dennis Q Berg <dberg3@csc.com>
Date: Fri, 01 Jul 2005 17:42:10 -0400
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 07/01/2005 05:41:19 PM
MIME-Version: 1.0
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df
Cc: Jason Michael Canon <fiatlux@adelphia.net>, ieprep-bounces@ietf.org, Janet P Gunn <jgunn6@csc.com>, jon.peterson@neustar.biz, "King, Kimberly S." <KIMBERLY.S.KING@saic.com>, ieprep@ietf.org, 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>
Content-Type: multipart/mixed; boundary="===============1149788296=="
Sender: ieprep-bounces@ietf.org
Errors-To: ieprep-bounces@ietf.org
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 8cb9b411340046bf4080a729180a0672




To help with your question:

GETS and WPS use priority feature, not preemption.

The FCC ruled on the legality of both GETS and WPS.  Specifically see, FCC
Report and Order, Establishment of Rules and Regulations for Priority
Access, Second Report and Order #96-86, 3 July 2000.

In compliance with the FCC R&O, functionality was designed and developed in
Wireless Priority Service to assure that the public is given adequate
access.  This feature, Resource Capacity Assurance for the Public (RCAP)
governs allocation of wireless radio resources between public and WPS
calls.  The current default reserves several times more capacity for the
public than for users of the priority service.  Extensive modeling and
analysis have been performed to predict the adequacy of the feature.  The
results show insignificant impact of WPS traffic on the public in a
spectrum of plausible congestion scenarios.

Hope that helps.

Dennis


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

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.
----------------------------------------------------------------------------------------




                                                                                                                                       
                      "Jason Michael                                                                                                   
                      Canon" <fiatlux          To:      "Jason Michael Canon" <fiatlux@adelphia.net>, "King, Kimberly S."              
                      @adelphia.net>           <KIMBERLY.S.KING@saic.com>, Janet P Gunn/FED/CSC@CSC                                    
                      Sent by:                 cc:      ieprep-bounces@ietf.org, jon.peterson@neustar.biz, ieprep@ietf.org,            
                      ieprep-bounces           sob@harvard.edu                                                                         
                                               Subject: Re: [Ieprep] Re-charter?                                                       
                                                                                                                                       
                      07/01/2005 04:58                                                                                                 
                      PM                                                                                                               
                                                                                                                                       
                                                                                                                                       




Sorry, I meant GETS/WPS and MLPP.

----- Original Message -----
From: "Jason Michael Canon" <fiatlux@adelphia.net>
To: "King, Kimberly S." <KIMBERLY.S.KING@saic.com>; "Janet P Gunn"
<jgunn6@csc.com>
Cc: <ieprep-bounces@ietf.org>; <ieprep@ietf.org>;
<jon.peterson@neustar.biz>; <sob@harvard.edu>
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" <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 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