RE: Re-charter? [MLPP limited to private nets]
"James M. Polk" <[email protected]> Tue, 05 Jul 2005 17:31:35 -0500
| Newsgroups | gmane.ietf.ieprep |
|---|---|
| Message-ID | <[email protected]> |
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: [email protected] > > [mailto:[email protected]]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: [email protected]; [email protected]; > > [email protected]; > > [email protected] > > Subject: Re: [Ieprep] 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 > > > > > > _______________________________________________ > > Ieprep mailing list > > [email protected] > > https://www1.ietf.org/mailman/listinfo/ieprep > > > > >_______________________________________________ >Ieprep mailing list >[email protected] >https://www1.ietf.org/mailman/listinfo/ieprep cheers, James ******************* Truth is not to be argued... it is to be presented.