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