RE: [Ieprep] Re-charter? [MLPP limited to private nets]

"James M. Polk" <jmpolk@cisco.com> Tue, 05 July 2005 22: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 SAA12765 for <ieprep-archive@ietf.org>; Tue, 5 Jul 2005 18:56:55 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpwbD-0006ne-RZ for ieprep-archive@ietf.org; Tue, 05 Jul 2005 19:13:12 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpw9H-0001w1-M9; Tue, 05 Jul 2005 18:44:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpw5X-0007dC-UC; Tue, 05 Jul 2005 18:40:27 -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 SAA10582; Tue, 5 Jul 2005 18:40:19 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpwO9-0003YI-6Z; Tue, 05 Jul 2005 18:59:37 -0400
Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 05 Jul 2005 15:31:42 -0700
X-IronPort-AV: i="3.93,263,1115017200"; d="scan'208"; a="290124476:sNHT88915394"
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j65MUxWB023127; Tue, 5 Jul 2005 15:31:39 -0700 (PDT)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Jul 2005 15:31:38 -0700
Received: from jmpolk-wxp.cisco.com ([10.21.120.51]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Jul 2005 15:31:37 -0700
Message-Id: <4.3.2.7.2.20050705172811.0262b6f0@email.cisco.com>
X-Sender: jmpolk@email.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 05 Jul 2005 17:31:35 -0500
To: Steve Silverman <steves@shentel.net>, Jason Michael Canon <fiatlux@adelphia.net>, "King, Kimberly S." <KIMBERLY.S.KING@saic.com>, Janet P Gunn <jgunn6@csc.com>
From: "James M. Polk" <jmpolk@cisco.com>
Subject: RE: [Ieprep] Re-charter? [MLPP limited to private nets]
In-Reply-To: <CIEELMKPOOAMCIAKANLBGEGNFBAA.steves@shentel.net>
References: <012b01c57e7f$911ed330$6401a8c0@canondownstairs>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-OriginalArrivalTime: 05 Jul 2005 22:31:37.0650 (UTC) FILETIME=[4E859920:01C581B1]
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 89ebdf268eceaeaf784b3acb625dc20e
Content-Transfer-Encoding: quoted-printable
Cc: ieprep-bounces@ietf.org, jon.peterson@neustar.biz, 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>
Sender: ieprep-bounces@ietf.org
Errors-To: ieprep-bounces@ietf.org
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 441f623df000f14368137198649cb083
Content-Transfer-Encoding: quoted-printable

Steve

At 06:17 PM 7/1/2005 -0400, Steve Silverman wrote:
>MLPP is not intended for the public network.

but... I have talked to many non-military customers that want it in their 
networks, so if the capability becomes available in products, others will 
use it.

>If you're on the DoD private network, the fact that you're using
>it means you have accepted the terms of service.

true true

>Given the number of high priority users, there is minimal impact on 
>routine traffic.
>
>One (I think ) outstanding question is whether 911 on the public net gets 
>any special priority. Right now we don't have a way to give
>priority to a call.

SIP RPH does this (even if it's only in ID format now)

>So your 911 call would be equally unintelligible.
>
>Steve Silverman
>
> > -----Original Message-----
> > From: ieprep-bounces@ietf.org
> > [mailto:ieprep-bounces@ietf.org]On Behalf
> > Of Jason Michael Canon
> > Sent: Friday, July 01, 2005 4:58 PM
> > To: Jason Michael Canon; King, Kimberly S.; Janet P Gunn
> > Cc: ieprep-bounces@ietf.org; jon.peterson@neustar.biz;
> > ieprep@ietf.org;
> > sob@harvard.edu
> > Subject: Re: [Ieprep] Re-charter?
> >
> >
> > 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


cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.

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