From mailman-bounces@ietf.org Fri Jul 1 05:28:58 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12585 for ; Fri, 1 Jul 2005 05:28:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoIFR-0007c7-9E for ieprep-archive@ietf.org; Fri, 01 Jul 2005 05:55:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoHUY-0001kB-5k for ieprep-archive@ietf.org; Fri, 01 Jul 2005 05:07:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: ieprep-archive@ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Jul 2005 05:02:25 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for ieprep-archive@ietf.org: List Password // URL ---- -------- ieprep@ietf.org totuar https://www1.ietf.org/mailman/options/ieprep/ieprep-archive%40ietf.org From ieprep-bounces@ietf.org Fri Jul 1 11:31:41 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06270 for ; Fri, 1 Jul 2005 11:31:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoNuV-0004Pk-2M for ieprep-archive@ietf.org; Fri, 01 Jul 2005 11:58:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoNTc-0007BV-KU; Fri, 01 Jul 2005 11:30:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoNTb-000788-FC; Fri, 01 Jul 2005 11:30:47 -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 LAA06212; Fri, 1 Jul 2005 11:30:42 -0400 (EDT) Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoNtW-0004Lv-2S; Fri, 01 Jul 2005 11:57:36 -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 j61FUQ5H005016; Fri, 1 Jul 2005 11:30:36 -0400 (EDT) Subject: Re: [Ieprep] Re-charter? To: "King, Kimberly S." X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Dennis Q Berg Date: Fri, 1 Jul 2005 11:17:21 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 07/01/2005 11:30:20 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.8 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: ieprep-bounces@ietf.org, "Jon Peterson \(jon.peterson@neustar.biz\)" , "Ieprep \(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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Just a logistic note to start. For discussion of the charter, and if there are also going to be any presentations, it strikes me that an hour is a bit short. Would it be possible to schedule a slot of at least an hour and a half? 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. ---------------------------------------------------------------------------------------- "King, Kimberly S." To: "Ieprep (ieprep@ietf.org)" 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 From ieprep-bounces@ietf.org Fri Jul 1 15:34:19 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03621 for ; Fri, 1 Jul 2005 15:34:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoRhN-0007yx-At for ieprep-archive@ietf.org; Fri, 01 Jul 2005 16:01:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoRGo-0000bu-T4; Fri, 01 Jul 2005 15:33:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoRGn-0000E4-QE; Fri, 01 Jul 2005 15:33:49 -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 PAA03530; Fri, 1 Jul 2005 15:33:43 -0400 (EDT) Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoRgl-0007p4-QW; Fri, 01 Jul 2005 16:00:41 -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 j61JXfPo008968; Fri, 1 Jul 2005 15:33:42 -0400 (EDT) In-Reply-To: <42C40623.7010303@cs.columbia.edu> Subject: Re: [Ieprep] Re-charter? To: Henning Schulzrinne X-Mailer: Lotus Notes 652HF83 November 04, 2004 Message-ID: From: Janet P Gunn Date: Fri, 1 Jul 2005 15:31:50 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 07/01/2005 03:33:26 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.8 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: "King, Kimberly S." , ieprep-bounces@ietf.org, "Jon Peterson \(jon.peterson@neustar.biz\)" , "Ieprep \(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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Closely related to the question "what is a session" is the question"what is pre-emption?" In the circuit switched world, a connection is "nailed up" and there is little confusion on what constitutes a "session" or "pre-emption". But in the IP world, even if we restrict our discussion to SIP related sessions, it is not so clear. Once a session has been established, how many packets need to be dropped, how bad does the "quality" need to get, before we declare that the session has "failed" or been "pre-empted"? Looking at it from another perspective, If traffic engineering indicates that a given (IP) interface or route can accept 100 simultaneous calls with a given QoS, but there is a mechanism to allow "special" calls to be accepted (without actually tearing down existing calls) above that threshold, at what point do I declare that the "special" calls are pre-empting "regular calls"? As soon as I exceed the engineered capacity(typically a utilization less than 100%)? Once I exceed the raw capacity (even though all calls may continue to meet the specified QoS)? When a single call drops below its QoS specification? For how long? And so on. While the CONCEPT of "pre-emption based" vs. "non-pre-emption based" carries over from the circuit switched world, and is useful in the IP world (especially when IP networks are operating under rules and regulations developed for the circuit switched world), the specific definition do not carry over with any intrinsic clarity. If we are going to go down this path, I think the first step is to agree on a consistent set of definitions. 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. ---------------------------------------------------------------------------------------- Henning Schulzrinne @cs.columbia.edu cc: "Jon Peterson \(jon.peterson@neustar.biz\)" > , sob@harvard.edu, "Ieprep \(ieprep@ietf.org\)" Sent by: ieprep-bounces Subject: Re: [Ieprep] Re-charter? 06/30/2005 10:48 AM Brief remark: I'm not sure what "sessions" refers to in the snippet below. Is this addressed to the application layer session (say, SIP), a network layer session (RSVP, NSIS) or something else entirely? In general, given the tortuous history of IEPREP discussions, more specificity as to the types of mechanisms and protocols affected would be helpful, in my opinion. Are there existing drafts that will be used as baseline (or input) or this is a from-scratch effort? King, Kimberly S. wrote: > 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. > _______________________________________________ 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 From ieprep-bounces@ietf.org Fri Jul 1 15:41:06 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04428 for ; Fri, 1 Jul 2005 15:41:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoRnv-0000Bg-IN for ieprep-archive@ietf.org; Fri, 01 Jul 2005 16:08:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoRMN-0008HY-Rm; Fri, 01 Jul 2005 15:39:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoRML-00086M-Up; Fri, 01 Jul 2005 15:39:34 -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 PAA04238; Fri, 1 Jul 2005 15:39:29 -0400 (EDT) Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoRmN-0008VG-Br; Fri, 01 Jul 2005 16:06:27 -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 j61JdW1R012389; Fri, 1 Jul 2005 15:39:32 -0400 (EDT) In-Reply-To: Subject: Re: [Ieprep] Re-charter?time slot? To: Dennis Q Berg X-Mailer: Lotus Notes 652HF83 November 04, 2004 Message-ID: From: Janet P Gunn Date: Fri, 1 Jul 2005 15:37:38 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 07/01/2005 03:39:16 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.8 (/) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 Cc: "King, Kimberly S." , ieprep-bounces@ietf.org, "Jon Peterson \(jon.peterson@neustar.biz\)" , "Ieprep \(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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 According to the IETF web site, July 5, Tuesday is the closing date for Working Group and BOF initial scheduling 17:00 ET (21:00 GMT) July 11, Monday is the Cutoff date for requests to reschedule Working Group and BOF meetings 09:00 ET (13:00 GMT) July 18, Monday is the closing date for Final Working Group and BOF scheduling 17:00 ET (21:00 GMT) So if there is a need for a longer slot, the request would need to be submitted very soon. 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. ---------------------------------------------------------------------------------------- Dennis Q Berg/FED/CSC To: "King, Kimberly S." @CSC cc: ieprep-bounces@ietf.org, "Jon Peterson Sent by: \(jon.peterson@neustar.biz\)" , "Ieprep ieprep-bounces \(ieprep@ietf.org\)" , sob@harvard.edu Subject: Re: [Ieprep] Re-charter? 07/01/2005 11:17 AM Just a logistic note to start. For discussion of the charter, and if there are also going to be any presentations, it strikes me that an hour is a bit short. Would it be possible to schedule a slot of at least an hour and a half? 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. ---------------------------------------------------------------------------------------- "King, Kimberly S." To: "Ieprep (ieprep@ietf.org)" 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 From ieprep-bounces@ietf.org Fri Jul 1 16:18:38 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16898 for ; Fri, 1 Jul 2005 16:18:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoSOC-0007gf-H1 for ieprep-archive@ietf.org; Fri, 01 Jul 2005 16:45:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoRjc-0001Ce-6s; Fri, 01 Jul 2005 16:03:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoRja-00011Y-1D; Fri, 01 Jul 2005 16:03:34 -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 QAA09718; Fri, 1 Jul 2005 16:03:31 -0400 (EDT) Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoS9a-00042L-NX; Fri, 01 Jul 2005 16:30:27 -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 j61K3UIT027268; Fri, 1 Jul 2005 16:03:31 -0400 (EDT) In-Reply-To: Subject: Re: [Ieprep] Re-charter? To: "King, Kimberly S." X-Mailer: Lotus Notes 652HF83 November 04, 2004 Message-ID: From: Janet P Gunn Date: Fri, 1 Jul 2005 16:01:39 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 07/01/2005 04:03:14 PM MIME-Version: 1.0 X-Spam-Score: 0.8 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: ieprep-bounces@ietf.org, "Jon Peterson \(jon.peterson@neustar.biz\)" , "Ieprep \(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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0432640122==" Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 --===============0432640122== Content-type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 DQoNCg0KDQpJIGhhdmUgYSBnZW5lcmljLCBoaWdoIGxldmVsIGNvbW1lbnQuDQoNCklmIHdlIGFy ZSBleHRlbmRpbmcgdGhlIGNoYXJ0ZXIgZnJvbSDigJxyZXF1aXJlbWVudHMgb25seeKAnSB0byDi gJxyZXF1aXJlbWVudHMNCmFuZCBzb2x1dGlvbnMgd2hlcmUgbm90IGNvdmVyZWQgZWxzZXdoZXJl 4oCdLCAgSSB0aGluayB0aGUgc29sdXRpb24gc3BhY2UNCnNob3VsZCBpbmNsdWRlIHNvbHV0aW9u cyBmb3Ig4oCcdGhlIGV2b2x1dGlvbiBvZiBHRVRTL1dQUyB0byBJUOKAnSBhcyB3ZWxsIGFzDQpz b2x1dGlvbnMgZm9yIOKAnHRoZSBldm9sdXRpb24gb2YgTUxQUCB0byBJUOKAnS4NCg0KU2ltaWxh cmx5LCB0aGUgcmVxdWlyZW1lbnRzIGFuZCBmcmFtZXdvcmtzIHRoYXQgaGF2ZSBiZWVuIHByZXZp b3VzbHkNCnByb2R1Y2VkIGNvdmVyIHRoZSBlbnRpcmUgSUVQUkVQIHNjb3BlLCBib3RoICJzb3J0 IG9mIGxpa2UgTUxQUCIgYW5kICJzb3J0DQpvZiBsaWtlIEdFVFMiLiAgU28gSSB0aGluayBpdCB3 b3VsZCBiZSBhcHByb3ByaWF0ZSB0byBoYXZlIGRlbGl2ZXJhYmxlcw0Kc3VjaCBhcw0KICJFbWVy Z2VuY3kgVGhyZWF0cyBBbmFseXNpcyBmb3IgQ29tbWVyY2lhbC9QdWJsaWMgTmV0d29ya3MiDQog IlJlcXVpcmVtZW50cyBmb3IgRW1lcmdlbmN5IFByZXBhcmVkbmVzcyBpbiBDb21tZXJjaWFsL1B1 YmxpYyBOZXR3b3JrcyINCiJQb3RlbnRpYWwgU29sdXRpb25zIGZvciBDb21tZXJjaWFsL1B1Ymxp YyBOZXR3b3JrcyINCiJNZWNoYW5pc21zIHRvIGJlIFVzZWQgYnkgQ29tbWVyY2lhbC9QdWJsaWMg TmV0d29ya3MiDQphcyB3ZWxsIGFzIHRoZSBvbmVzIHByb3Bvc2VkIGZvciAiR292ZXJubWVudC9N aWxpdGFyeSBOZXR3b3JrcyIuDQoNCkkgdGhpbmsgdGhhdCB3b3VsZCBiZSBtb3JlIHVzZWZ1bCB0 aGFuICJEaWZmZXJlbmNlcyBiZXR3ZWVuIEdFVFMgYW5kIE1MUFANCm5ldHdvcmtzIiwgZXNwZWNp YWxseSBzaW5jZSBzb21lIG9mIHRoZSBkaWZmZXJlbmNlcyB3aGljaCBhcmUgc2lnbmlmaWNhbnQN CmluIHRoZSBjaXJjdWl0IHN3aXRjaGVkIHdvcmxkIG1heSBiZSBsZXNzIHNpZ25pZmljYW50IGlu IHRoZSBwYWNrZXQNCnN3aXRjaGVkIHdvcmxkLiAgQnV0IG1heWJlIGlmIEkgc2F3IGFuIGFic3Ry YWN0IG9mIHdoYXQgd2FzIGludGVuZGVkIGZvcg0KdGhlIGRvY3VtZW50LCBJIHdvdWxkIGNoYW5n ZSBteSBtaW5kLg0KDQpKYW5ldA0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cg0KVGhpcyBpcyBhIFBSSVZBVEUgbWVzc2FnZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk IHJlY2lwaWVudCwgcGxlYXNlDQpkZWxldGUgd2l0aG91dCBjb3B5aW5nIGFuZCBraW5kbHkgYWR2 aXNlIHVzIGJ5IGUtbWFpbCBvZiB0aGUgbWlzdGFrZSBpbg0KZGVsaXZlcnkuIE5PVEU6IFJlZ2Fy ZGxlc3Mgb2YgY29udGVudCwgdGhpcyBlLW1haWwgc2hhbGwgbm90IG9wZXJhdGUgdG8NCmJpbmQg Q1NDIHRvIGFueSBvcmRlciBvciBvdGhlciBjb250cmFjdCB1bmxlc3MgcHVyc3VhbnQgdG8gZXhw bGljaXQgd3JpdHRlbg0KYWdyZWVtZW50IG9yIGdvdmVybm1lbnQgaW5pdGlhdGl2ZSBleHByZXNz bHkgcGVybWl0dGluZyB0aGUgdXNlIG9mIGUtbWFpbA0KZm9yIHN1Y2ggcHVycG9zZS4NCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAg ICAgICAgICAgICAgICJLaW5nLCBLaW1iZXJseSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IA0KICAgICAgICAgICAgICAgICAgICAgIFMuIiAgICAgICAgICAgICAgICAgICAgICBUbzogICAg ICAiSWVwcmVwIChpZXByZXBAaWV0Zi5vcmcpIiA8aWVwcmVwQGlldGYub3JnPiAgICAgICAgICAg ICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgIDxLSU1CRVJMWS5TLktJTkcgICAg ICAgICBjYzogICAgICBzb2JAaGFydmFyZC5lZHUsICJKb24gUGV0ZXJzb24gXChqb24ucGV0ZXJz b25AbmV1c3Rhci5iaXpcKSIgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgIEBzYWljLmNv bT4gICAgICAgICAgICAgICA8am9uLnBldGVyc29uQG5ldXN0YXIuYml6PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAg ICAgIFNlbnQgYnk6ICAgICAgICAgICAgICAgICBTdWJqZWN0OiBbSWVwcmVwXSBSZS1jaGFydGVy PyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAg ICAgICAgICAgICAgICAgIGllcHJlcC1ib3VuY2VzICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgIDA2LzMw LzIwMDUgMTA6MjQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAg ICAgICAgIEFNICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIA0KDQoNCg0KDQoNClNjb3R0IGFuZCBJIGhhdmUgYXNrZWQgZm9yIGEgMSBob3VyIG1l ZXRpbmcgc2xvdCBhdA0KdGhlIFBhcmlzIElFVEYgbWVldGluZyB0byBkaXNjdXNzIGEgcG9zc2li bGUgcmUtY2hhcnRlcg0Kb2YgaWVwcmVwLiAgQSBwcm92aXNpb25hbCBuZXcgY2hhcnRlciBpcyBp bmNsdWRlZCBiZWxvdy4NCg0KS2ltYmVybHkNCg0KDQoqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKg0KRHJhZnQgcmV2aXNpb24NCkludGVybmV0IEVtZXJnZW5jeSBQcmVw YXJlZG5lc3MgKGllcHJlcCkgQ2hhcnRlcg0KDQpEZXNjcmlwdGlvbiBvZiBXb3JraW5nIEdyb3Vw Og0KDQpFZmZlY3RpdmUgdGVsZWNvbW11bmljYXRpb25zIGNhcGFiaWxpdGllcyBhcmUgaW1wZXJh dGl2ZSB0bw0KZmFjaWxpdGF0ZSBpbW1lZGlhdGUgcmVjb3Zlcnkgb3BlcmF0aW9ucyBmb3Igc2Vy aW91cw0KZGlzYXN0ZXIgZXZlbnRzIGluY2x1ZGluZyBuYXR1cmFsIGRpc2FzdGVycyAoZS5nLiwN Cmh1cnJpY2FuZXMsIGZsb29kcywgZWFydGhxdWFrZXMpIGFuZCB0aG9zZSBjcmVhdGVkIGJ5IG1h bg0KKGUuZy4sIHRlcnJvcmlzdCBhdHRhY2tzLCBjb21iYXQgc2l0dWF0aW9ucyBvciB3YXJ0aW1l DQpldmVudHMpLiAgSW4gYWRkaXRpb24sIHJlbGF0ZWQgY2FwYWJpbGl0aWVzIHNob3VsZCBiZSB1 c2FibGUNCmluIG5vcm1hbCBjb21tYW5kIGFuZCBjb250cm9sIG9wZXJhdGlvbnMgb2YgbWlsaXRh cnkNCnNlcnZpY2VzLCB3aGljaCBvZnRlbiBoYXZlIHRpbWVsaW5lc3MgcmVxdWlyZW1lbnRzIGV2 ZW4gaW4NCnBlYWNldGltZS4gIFRoZSBJRVBSRVAgV0cgd2lsbCBhZGRyZXNzIHByb2FjdGl2ZSBh bmQNCnJlYWN0aXZlIHJvYnVzdG5lc3MgYW5kIHJlY292ZXJ5IGZyb20gdmFyaW91cyBvdXRhZ2Vz IHVzaW5nDQp0aHJlZSBwZXJzcGVjdGl2ZXM6DQoNCjEuIEEgY29tbWVyY2lhbCAoaS5lLiwgb3Ig cHVibGljKSB0ZWxlY29tbXVuaWNhdGlvbnMNCmluZnJhc3RydWN0dXJlDQoNCjIuIEEgZ292ZXJu bWVudGFsL21pbGl0YXJ5IHRlbGVjb21tdW5pY2F0aW9ucyBpbmZyYXN0cnVjdHVyZQ0KdGhhdCBt YXkgcmV0YWlucyBzb2xlIG93bmVyc2hpcCBhbmQgYWRtaW5pc3RyYXRpb24gb2YgaXRzDQpvd24g cmVzb3VyY2VzDQoNCjMuIEEgZ292ZXJubWVudGFsL21pbGl0YXJ5IHRlbGVjb21tdW5pY2F0aW9u cyBpbmZyYXN0cnVjdHVyZQ0KdGhhdCBjb21iaW5lcyBwcml2YXRlIHJlc291cmNlcyBhbmQgbGV2 ZXJhZ2VzIHB1YmxpYw0KaW5mcmFzdHJ1Y3R1cmUuICBUaGlzIHNjZW5hcmlvIG1heSBiZSBzdWJq ZWN0IHRvIGxvY2FsDQpwb2xpY2llcywgbGF3cywgYW5kIHJlZ3VsYXRpb25zLg0KDQpEaXNhc3Rl cnMgY2FuIGhhcHBlbiBhbnkgdGltZSwgYW55IHBsYWNlLCB1bmV4cGVjdGVkbHkuDQpRdWljayBy ZXNwb25zZSBmb3IgcmVjb3Zlcnkgb3BlcmF0aW9ucyByZXF1aXJlcyBpbW1lZGlhdGUNCmFjY2Vz cyB0byBhbnkgcHVibGljIHRlbGVjb21tdW5pY2F0aW9ucyBjYXBhYmlsaXRpZXMgYXQNCmhhbmQu IFRoZXNlIGNhcGFiaWxpdGllcyBpbmNsdWRlOiBjb252ZW50aW9uYWwgdGVsZXBob25lLA0KY2Vs bHVsYXIgcGhvbmVzLCBhbmQgSW50ZXJuZXQgYWNjZXNzIHZpYSBvbmxpbmUgdGVybWluYWxzLA0K SVAgdGVsZXBob25lcywgYW5kIHdpcmVsZXNzIFBEQXMuIFRoZSBjb21tZXJjaWFsDQp0ZWxlY29t bXVuaWNhdGlvbnMgaW5mcmFzdHJ1Y3R1cmUgaXMgcmFwaWRseSBldm9sdmluZyB0bw0KSW50ZXJu ZXQtYmFzZWQgdGVjaG5vbG9neS4gIFRoZXJlZm9yZSwgdGhlIEludGVybmV0DQpjb21tdW5pdHkg bmVlZHMgdG8gY29uc2lkZXIgaG93IGl0IGNhbiBiZXN0IHN1cHBvcnQNCmVtZXJnZW5jeSBtYW5h Z2VtZW50IGFuZCByZWNvdmVyeSBvcGVyYXRpb25zLg0KDQpQb3RlbnRpYWwgZGlzYXN0ZXJzIGZv ciBnb3Zlcm5tZW50YWwvbWlsaXRhcnkNCmluZnJhc3RydWN0dXJlcyBjYW4gZXh0ZW5kIGJleW9u ZCB3aGF0IG1pZ2h0IGJlIGV4cGVyaWVuY2VkDQpieSB0aGUgY29tbWVyY2lhbC9wdWJsaWMgc2Vj dG9yIGFuZCBjYW4gYmUgYW50aWNpcGF0ZWQgdG8NCnNvbWUgZGVncmVlLiAgVGh1cywgcHJvYWN0 aXZlIG1lY2hhbmlzbXMgdG8gYWRkcmVzcyB3b3VsZC1iZQ0Kb3V0YWdlcyBhcmUgcmVxdWlyZWQg Zm9yIHRoZXNlIHNjZW5hcmlvcy4NCg0KVGhlIElFUFJFUCBXRyB3aWxsIHdvcmsgb24gdGhlc2Ug dGhyZWUgcGVyc3BlY3RpdmVzDQooY29tbWVyY2lhbCwgZ292ZXJubWVudGFsL21pbGl0YXJ5LCBh bmQgdGhlIGNvbWJpbmF0aW9uKSBhbmQNCnN5bmVyZ2l6ZSBjb21tb24gbWVjaGFuaXNtcyBhbmQg cmVxdWlyZW1lbnRzIGludG8gb3RoZXINCmdyb3VwcyB3aGVyZSBwb3NzaWJsZSwgd2hpbGUgbWFp bnRhaW5pbmcgYSBzZXBhcmF0ZSB0cmFjayBvZg0KSUVQUkVQIGRvY3VtZW50cyBmb3IgdGhlIHVu aXF1ZSBtZWNoYW5pc21zIGFuZCByZXF1aXJlbWVudHMNCm9mIGVhY2ggcGVyc3BlY3RpdmVzLg0K DQpOb3cgdGhhdCB0aGUgaW5pdGlhbCBkb2N1bWVudHMgZGVzY3JpYmUgdGhlIGJyb2FkIHByb2Js ZW0NCnNwYWNlIGFuZCBpdHMgc2FsaWVudCBjaGFyYWN0ZXJpc3RpY3MsIG5ldyBlZmZvcnRzIHdp bGwNCmZvY3VzIG9uIHNwZWNpZmljIHJlcXVpcmVtZW50cyBhbmQgc29sdXRpb25zIHN1Y2ggYXMg dGhvc2UNCnBlcnRhaW5pbmcgdG8gdGhlIGdvdmVybm1lbnRhbC9taWxpdGFyeSBzZWN0b3IuICBP bmUNCmRvY3VtZW50IGV4aXN0cyBpbiB0aGUgVHJhbnNwb3J0IEFyZWEgd29ya2luZyBncm91cCBv Zg0KaW50ZXJlc3QgdG8gSUVQUkVQIHRoYXQgY291bGQgc2F0aXNmeSBhIGdvdmVybm1lbnRhbA0K ZnJhbWV3b3JrL0JDUCBpcyBkcmFmdC1pZXRmLXRzdndnLW1scHAtdGhhdC13b3Jrcy1YWC4gIFRo aXMNCmRvY3VtZW50IHdpbGwgcHJvZ3Jlc3MgdG8gY29tcGxldGlvbiBpbiB0aGF0IFdHLCB5ZXQg YmUgdGhlDQpiYXNpcyBvZiBtb3JlIHdvcmsgaW4gdGhpcyBJRVBSRVAgV0cuICBTb21lIGFkZGl0 aW9uYWwNCmVmZm9ydHMgb24gdGhlIGdvdmVybm1lbnRhbC9taWxpdGFyeSB0cmFjayB3aXRoaW4g SUVQUkVQDQp3aWxsIGZvY3VzIG9uIHRoaXMgVFNWV0cgZG9jdW1lbnQsIGFuYWx5emUgZ2Fwcywg YW5kIHByb3ZpZGUNCmlucHV0IHdoZXJlIG5lZWRlZC4NCg0KVGhlIGZvbGxvd2luZyBhcmUgZm91 ciBzcGVjaWZpYyBleGFtcGxlcyB0aGF0IGNhbiBzYXRpc2Z5DQp0aGUgaW50ZXJlc3RzIG9mIGdv dmVybm1lbnRhbC9taWxpdGFyeSAoYW5kIHBvdGVudGlhbGx5LA0KY29tbWVyY2lhbC9wdWJsaWMp IGVtZXJnZW5jeSBjb21tdW5pY2F0aW9uczoNCg0KMS4gQ29udmV5aW5nIGluZm9ybWF0aW9uIGFi b3V0IHRoZSBwcmlvcml0eSBvZiBzcGVjaWZpYw0KZmxvd3MgKG9yIHNlc3Npb25zKSB0aGF0IG9y aWdpbmF0ZSBpbiBhIFZvSVAgZW52aXJvbm1lbnQuDQpUaGlzIGNvdWxkIGluY2x1ZGUgYSByZXF1 aXJlbWVudHMgZWZmb3J0IHRvIGRlc2NyaWJlDQpleHRlbnNpb25zIHRvIE5TSVMgb3IgUlNWUC4g UmVxdWlyZW1lbnRzIGZvciBOU0lTIHdvdWxkIGJlDQpmb3J3YXJkZWQgdG8gdGhlIE5TSVMgd29y a2luZyBncm91cC4gUmVxdWlyZW1lbnRzIGZvciBSU1ZQDQpjb3VsZCBiZSBmb3J3YXJkZWQgdG8g dHN2d2cgb3Igd29ya2VkIG9uIGluIElFUFJFUC4NCg0KMi4gTmVzdGVkIFZQTnMgcmVxdWlyZSBz cGVjaWFsIGNvbnNpZGVyYXRpb25zIGZvciByb3V0aW5nDQphbmQgUW9TIGlmIG5vZGVzIGluIHRo ZSBwYXRoIHRoYXQgbWFrZSB0aGVzZSBkZWNpc2lvbnMNCmdlbmVyYWxseSBoYXZlIGxpbWl0ZWQg aW5mb3JtYXRpb24uDQoNCjMuIFNvbWUgY291bnRyaWVzIHJlcXVpcmUgY2l2aWwgbmV0d29ya3Mg dG8gcHJlZW1wdCBzZXNzaW9ucw0KdW5kZXIgc3RhdGUgY2lyY3Vtc3RhbmNlcywgYW5kIHByZWVt cHRpb24gaXMgY29uc2lkZXJlZCBhbg0KYWJzb2x1dGUgcmVxdWlyZW1lbnQgaW4gZ292ZXJubWVu dGFsIG5ldHdvcmtzIGluIG1vc3QNCmNvdW50cmllcy4gVW5sZXNzIGltcGxlbWVudGF0aW9uIG9m IHRoZXNlIHJlcXVpcmVtZW50cyBjYW4NCmJlIG9iamVjdGl2ZWx5IHNob3duIHRvIHRocmVhdGVu IG5ldHdvcmsgaGVhbHRoICh2aWENCnNpbXVsYXRpb24gb3IgaW4gb3BlcmF0aW9ucyksIHRoZW4g dGhlIHJlcXVpcmVtZW50IG5lZWRzIHRvDQpiZSBjb25zaWRlcmVkIGJ5IElFUFJFUCBhbmQgc3Bl Y2lmaWMgc29sdXRpb25zIG11c3QgYmUNCmRldmVsb3BlZC4NCg0KNC4gTm9uLXJlYWwtdGltZSBh cHBsaWNhdGlvbnMgcmVxdWlyZSBtZWFzdXJlcyBvZiBRb1MgYW5kDQpvdGhlciBwcmVmZXJlbnRp YWwgdHJlYXRtZW50cywgYXMgdm9pY2Ugd2lsbCBub3QgYmUgdGhlIG9ubHkNCmFwcGxpY2F0aW9u IHVzZWQgYnkgSUVQUkVQLg0KDQpJbiB0aGUgSUVURiwgY29uc2lkZXJhdGlvbnMgZm9yIHRyZWF0 bWVudCBhbmQgc2VjdXJpdHkgb2YNCmVtZXJnZW5jeSBjb21tdW5pY2F0aW9ucyBzdHJldGNoIGFj cm9zcyBhIG51bWJlciBvZiBBcmVhcw0KYW5kIFdvcmtpbmcgR3JvdXBzLCBub3RhYmx5IGluY2x1 ZGluZyB0aGUgdmFyaW91cyB0ZWxlcGhvbnkNCnNpZ25hbGluZyB3b3JraW5nIGdyb3VwcywgUHJv dG9jb2wgZm9yIGNhcnJ5aW5nDQpBdXRoZW50aWNhdGlvbiBmb3IgTmV0d29yayBBY2Nlc3MgKHBh bmEpLCB0aGUgb3BlbiBUcmFuc3BvcnQNCkFyZWEgZm9yIHBhdGgtY291cGxlZCBzaWduYWxpbmcg YW5kIHZhcmlvdXMgb3BlcmF0aW9uYWwNCmdyb3Vwcy4gSUVQUkVQIHdpbGwgY29vcGVyYXRlIGNs b3NlbHkgd2l0aCB0aGVzZSBncm91cHMgYW5kDQp3aXRoIHRob3NlIG91dHNpZGUgb2YgdGhlIElF VEYgc3VjaCBhcyB2YXJpb3VzIElUVS1UIHN0dWR5DQpncm91cHMuDQoNCg0KSWYgdGhlcmUgaXMg YW4gZXhpc3RpbmcgV0cgdGhhdCBjYW4gZGlzY3VzcyB0aGUgcmVxdWlyZW1lbnRzDQpmb3IgZXh0 ZW5kaW5nIHRoZWlyIHByb3RvY29sIG9yIG1lY2hhbmlzbSwgSUVQUkVQIHdpbGwNCmdlbmVyYXRl IG9ubHkgYSByZXF1aXJlbWVudHMgZG9jdW1lbnQgZm9yIHRoYXQgZ3JvdXAgdG8NCmRpc2N1c3Mu DQoNCklmIHRoZXJlIGlzIG5vdCBhbiBleGlzdGluZyBXRyB0aGF0IGNhbiBkaXNjdXNzIHRoZQ0K cmVxdWlyZW1lbnRzIGZvciBleHRlbmRpbmcgdGhlaXIgcHJvdG9jb2wgb3IgbWVjaGFuaXNtLA0K SUVQUkVQIHdpbGwgcHJlcGFyZSByZXF1aXJlbWVudHMgYW5kIGRpc2N1c3MgdGhlIGV4dGVuc2lv bg0Kb2YgdGhhdCBwcm90b2NvbC9tZWNoYW5pc20gb3IgcHJvdG9jb2xzL21lY2hhbmlzbXMgd2l0 aGluDQpJRVBSRVAuDQoNCg0KR29hbHMgYW5kIE1pbGVzdG9uZXM6DQoNCkRvbmUgICBTdWJtaXQg aW5pdGlhbCBJLUQgb2YgUmVxdWlyZW1lbnRzDQoNCkRvbmUgICBTdWJtaXQgaW5pdGlhbCBJLUQg b2YgRnJhbWV3b3JrDQoNCkRvbmUgICBTdWJtaXQgaW5pdGlhbCBJLUQgb2YgUmVjb21tZW5kYXRp b25zIEJDUA0KDQpEb25lICAgU3VibWl0IFJlcXVpcmVtZW50cyBJLUQgdG8gSUVTRyBmb3IgcHVi bGljYXRpb24gYXMgYW4NCiAgICAgICBJbmZvcm1hdGlvbmFsIFJGQw0KDQpEb25lICAgU3VibWl0 IEZyYW1ld29yayBJLUQgdG8gSUVTRyBmb3IgcHVibGljYXRpb24gYXMgYW4NCkluZm9ybWF0aW9u YWwgUkZDDQoNCkRlYyAwMyBTdWJtaXQgUmVjb21tZW5kYXRpb25zIEktRCB0byBJRVNHIGZvciBw dWJsaWNhdGlvbiBhcw0KYSBCQ1ANCg0KT2N0IDA1IFN1Ym1pdCBhbiBpbml0aWFsIEktRCBvZiBF bWVyZ2VuY3kgVGhyZWF0cyBBbmFseXNpcw0Kb2YgR292ZXJubWVudC9NaWxpdGFyeSBOZXR3b3Jr cw0KDQpEZWMgMDUgU3VibWl0IGFuIGluaXRpYWwgSS1EIG9mIERpZmZlcmVuY2VzIGJldHdlZW4g R0VUUyBhbmQNCk1MUFAgTmV0d29ya3MNCg0KRmViIDA2IFN1Ym1pdCBhbiBpbml0aWFsIEktRCBv ZiBSZXF1aXJlbWVudHMgb2YNCkdvdmVybm1lbnQvTWlsaXRhcnkgTmV0d29ya3MNCg0KTWFyIDA2 IFN1Ym1pdCBhbiBpbml0aWFsIEktRCBvZiBDb25zaWRlcmF0aW9ucyBmb3IgcG90ZW50aWFsDQpz b2x1dGlvbnMgb2YgR292ZXJubWVudC9NaWxpdGFyeSBOZXR3b3Jrcw0KDQpBcHIgMDYgU3VibWl0 IGFuIGluaXRpYWwgSS1EIG9mIE1lY2hhbmlzbXMgdG8gYmUgdXNlZCBieQ0KICAgICAgIEdvdmVy bm1lbnQvTWlsaXRhcnkgTmV0d29ya3MNCg0KT2N0IDA1IFN1Ym1pdCBmaW5hbCBJLUQgb2YgRW1l cmdlbmN5IFRocmVhdHMgQW5hbHlzaXMgb2YNCiAgICAgICBHb3Zlcm5tZW50L01pbGl0YXJ5IE5l dHdvcmtzIHRvIElFU0cgYXMgSW5mb3JtYXRpb25hbA0KUkZDDQoNCkZlYiAwNiBTdWJtaXQgZmlu YWwgSS1EIG9mIFJlcXVpcmVtZW50cyBvZg0KR292ZXJubWVudC9NaWxpdGFyeSBOZXR3b3JrcyB0 byBJRVNHIGFzIEluZm9ybWF0aW9uYWwgUkZDDQoNCkFwciAwNiBTdWJtaXQgZmluYWwgSS1EIG9m IE1lY2hhbmlzbXMgdG8gYmUgdXNlZCBieQ0KICAgICAgIEdvdmVybm1lbnQvTWlsaXRhcnkgTmV0 d29ya3MgdG8gSUVTRyBhcyBCQ1AgUkZDDQoNClRoZSB3b3JraW5nIGdyb3VwIHdpbGwgZGlzY3Vz cyByZS1jaGFydGVyaW5nIGlmIGFkZGl0aW9uYWwNCmVmZm9ydHMgYXJlIGFncmVlZCB1cG9uIGJ5 IHRoZSBXRyAoZm9yIGV4YW1wbGUsIHdvcmsgaXRlbXMNCnJlbGF0ZWQgdG8gcHJvdG9jb2xzIG91 dHNpZGUgZXhpc3RpbmcgV0dzKS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCkllcHJlcCBtYWlsaW5nIGxpc3QNCkllcHJlcEBpZXRmLm9yZw0KaHR0 cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWVwcmVwDQo= --===============0432640122== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep --===============0432640122==-- From ieprep-bounces@ietf.org Fri Jul 1 16:56:02 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21264 for ; Fri, 1 Jul 2005 16:56:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoSyQ-0003iQ-Qj for ieprep-archive@ietf.org; Fri, 01 Jul 2005 17:22:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoSWr-0000Fx-0U; Fri, 01 Jul 2005 16:54:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoSWm-0008VE-4g; Fri, 01 Jul 2005 16:54:26 -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 QAA21042; Fri, 1 Jul 2005 16:54:21 -0400 (EDT) Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoSwn-0003cN-P5; Fri, 01 Jul 2005 17:21:18 -0400 Received: from canondownstairs ([68.65.34.212]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050701205407.NYQF19267.mta10.adelphia.net@canondownstairs>; Fri, 1 Jul 2005 16:54:07 -0400 Message-ID: <011401c57e7f$05227da0$6401a8c0@canondownstairs> From: "Jason Michael Canon" To: "King, Kimberly S." , "Janet P Gunn" References: Subject: Re: [Ieprep] Re-charter? Date: Fri, 1 Jul 2005 16:54:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Score: 0.9 (/) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA21042 Cc: ieprep-bounces@ietf.org, ieprep@ietf.org, jon.peterson@neustar.biz, sob@harvard.edu X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 Content-Transfer-Encoding: quoted-printable I have a generic, high level question. As a civilian in an emergency situation I call 9-1-1 to report some life=20 threatening situation in my house. While the call is in progress a sufficient number of government=20 officials evoke a GETS/WAS or MOP capability and my call is effectively preempted or degraded to a=20 level that is not tolerable. My question is did a public policy debate result in a Congressional law o= r=20 FCC Regulation that permits the ITEM to craft enabling technology? If so, a reference to the documen= t=20 would be greatly appreciated. Thanks, Jason ----- Original Message -----=20 From: "Janet P Gunn" To: "King, Kimberly S." Cc: ; ;=20 ; 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 =E2=80=9Crequirements only=E2=80=9D= to =E2=80=9Crequirements > and solutions where not covered elsewhere=E2=80=9D, I think the soluti= on space > should include solutions for =E2=80=9Cthe evolution of GETS/WPS to IP=E2= =80=9D as well as > solutions for =E2=80=9Cthe evolution of MLPP to IP=E2=80=9D. > > Similarly, the requirements and frameworks that have been previously > produced cover the entire IEPREP scope, both "sort of like MLPP" and "s= ort > 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 ML= PP > networks", especially since some of the differences which are significa= nt > 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 fo= r > the document, I would change my mind. > > Janet > > > -----------------------------------------------------------------------= ----------------- > > This is a PRIVATE message. If you are not the intended recipient, pleas= e > 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=20 > written > agreement or government initiative expressly permitting the use of e-ma= il > for such purpose. > -----------------------------------------------------------------------= ----------------- > > > > > > "King, Kimberly > S." To: "Ieprep=20 > (ieprep@ietf.org)" > "Jon Peterson \(jon.peterson@neustar.biz\)" > @saic.com> > Sent by: Subject: [Ieprep]=20 > 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 >=20 _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Fri Jul 1 17:00:00 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21690 for ; Fri, 1 Jul 2005 17:00:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoT2H-0004Kb-AJ for ieprep-archive@ietf.org; Fri, 01 Jul 2005 17:26:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoSaY-000364-SA; Fri, 01 Jul 2005 16:58:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoSaS-0002mx-6s; Fri, 01 Jul 2005 16:58:17 -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 QAA21508; Fri, 1 Jul 2005 16:58:09 -0400 (EDT) Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoT0U-00040n-4R; Fri, 01 Jul 2005 17:25:06 -0400 Received: from canondownstairs ([68.65.34.212]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050701205801.XDMD29002.mta9.adelphia.net@canondownstairs>; Fri, 1 Jul 2005 16:58:01 -0400 Message-ID: <012b01c57e7f$911ed330$6401a8c0@canondownstairs> From: "Jason Michael Canon" To: "Jason Michael Canon" , "King, Kimberly S." , "Janet P Gunn" References: <011401c57e7f$05227da0$6401a8c0@canondownstairs> Subject: Re: [Ieprep] Re-charter? Date: Fri, 1 Jul 2005 16:58:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Score: 0.9 (/) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA21508 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b Content-Transfer-Encoding: quoted-printable Sorry, I meant GETS/WPS and MLPP. ----- Original Message -----=20 From: "Jason Michael Canon" To: "King, Kimberly S." ; "Janet P Gunn"=20 Cc: ; ;=20 ; 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 o= r FCC Regulation that permits the ITEM to craft enabling technology? If so, a reference to the documen= t would be greatly appreciated. Thanks, Jason ----- Original Message -----=20 From: "Janet P Gunn" To: "King, Kimberly S." Cc: ; ; ; 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 =E2=80=9Crequirements only=E2=80=9D= to =E2=80=9Crequirements > and solutions where not covered elsewhere=E2=80=9D, I think the soluti= on space > should include solutions for =E2=80=9Cthe evolution of GETS/WPS to IP=E2= =80=9D as well as > solutions for =E2=80=9Cthe evolution of MLPP to IP=E2=80=9D. > > Similarly, the requirements and frameworks that have been previously > produced cover the entire IEPREP scope, both "sort of like MLPP" and "s= ort > 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 ML= PP > networks", especially since some of the differences which are significa= nt > 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 fo= r > the document, I would change my mind. > > Janet > > > -----------------------------------------------------------------------= ----------------- > > This is a PRIVATE message. If you are not the intended recipient, pleas= e > 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=20 > written > agreement or government initiative expressly permitting the use of e-ma= il > for such purpose. > -----------------------------------------------------------------------= ----------------- > > > > > > "King, Kimberly > S." To: "Ieprep=20 > (ieprep@ietf.org)" > "Jon Peterson \(jon.peterson@neustar.biz\)" > @saic.com> > Sent by: Subject: [Ieprep]=20 > 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=20 _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Fri Jul 1 17:20:44 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23667 for ; Fri, 1 Jul 2005 17:20:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoTML-0006g8-Ub for ieprep-archive@ietf.org; Fri, 01 Jul 2005 17:47:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoSw5-0008W0-Ee; Fri, 01 Jul 2005 17:20:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoSw3-0008Nt-Iw; Fri, 01 Jul 2005 17:20:31 -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 RAA23652; Fri, 1 Jul 2005 17:20:28 -0400 (EDT) Received: from syd-iport-1.cisco.com ([64.104.193.196]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoTM4-0006fk-TX; Fri, 01 Jul 2005 17:47:26 -0400 Received: from syd-core-1.cisco.com (64.104.193.198) by syd-iport-1.cisco.com with ESMTP; 02 Jul 2005 07:47:35 +1000 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by syd-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j61LJZ91011587; Sat, 2 Jul 2005 07:19:36 +1000 (EST) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j61LJUgp015504; Fri, 1 Jul 2005 14:19:30 -0700 In-Reply-To: <011401c57e7f$05227da0$6401a8c0@canondownstairs> References: <011401c57e7f$05227da0$6401a8c0@canondownstairs> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6cc94ad777b0f294a06fcbd2a1a3aa1d@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [Ieprep] Re-charter? Date: Fri, 1 Jul 2005 14:20:06 -0700 To: "Jason Michael Canon" X-Mailer: Apple Mail (2.622) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1120252770.694679"; x:"432200"; a:"rsa-sha1"; b:"nofws:431"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"GFfY/xEUvALMbokrFfDHgqHFKv0leZqWF6YqB+S6C4BUUlYYQTQbFzdP97K1rCvZR65UC4uQ" "EyFKiLR6eOZA3g5hmM81LF/9zZcox0HujWkTA1gwk+GAUTnBsZJZSFdTuvmaH6Bo5APCcEH0ry8" "kebto7DOi47iWtXIuWJi3RAI="; c:"From: Fred Baker "; c:"Subject: Re: [Ieprep] Re-charter?"; c:"Date: Fri, 1 Jul 2005 14:20:06 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: ieprep-bounces@ietf.org, jon.peterson@neustar.biz, Janet P Gunn , "King, Kimberly S." , 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit On Jul 1, 2005, at 1:54 PM, Jason Michael Canon wrote: > My question is did a public policy debate result in a Congressional > law or FCC Regulation that permits > the ITEM to craft enabling technology? Someone has to pass a law before we get to develop a protocol? What law permitted us to develop the Internet? Please. We are not permitted to do things that law/regulation precludes. If law/regulation doesn't preclude something, we don't have to bow and scrape in front of a regulator to get permission to think about it. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Fri Jul 1 17:44:53 2005 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 ; 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" X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Dennis Q Berg Date: Fri, 1 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 , ieprep-bounces@ietf.org, Janet P Gunn , jon.peterson@neustar.biz, "King, Kimberly S." , 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 List-Unsubscribe: , List-Post: List-Help: List-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 --===============1149788296== Content-type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 DQoNCg0KDQpUbyBoZWxwIHdpdGggeW91ciBxdWVzdGlvbjoNCg0KR0VUUyBhbmQgV1BTIHVzZSBw cmlvcml0eSBmZWF0dXJlLCBub3QgcHJlZW1wdGlvbi4NCg0KVGhlIEZDQyBydWxlZCBvbiB0aGUg bGVnYWxpdHkgb2YgYm90aCBHRVRTIGFuZCBXUFMuICBTcGVjaWZpY2FsbHkgc2VlLCBGQ0MNClJl cG9ydCBhbmQgT3JkZXIsIEVzdGFibGlzaG1lbnQgb2YgUnVsZXMgYW5kIFJlZ3VsYXRpb25zIGZv ciBQcmlvcml0eQ0KQWNjZXNzLCBTZWNvbmQgUmVwb3J0IGFuZCBPcmRlciAjOTYtODYsIDMgSnVs eSAyMDAwLg0KDQpJbiBjb21wbGlhbmNlIHdpdGggdGhlIEZDQyBSJk8sIGZ1bmN0aW9uYWxpdHkg d2FzIGRlc2lnbmVkIGFuZCBkZXZlbG9wZWQgaW4NCldpcmVsZXNzIFByaW9yaXR5IFNlcnZpY2Ug dG8gYXNzdXJlIHRoYXQgdGhlIHB1YmxpYyBpcyBnaXZlbiBhZGVxdWF0ZQ0KYWNjZXNzLiAgVGhp cyBmZWF0dXJlLCBSZXNvdXJjZSBDYXBhY2l0eSBBc3N1cmFuY2UgZm9yIHRoZSBQdWJsaWMgKFJD QVApDQpnb3Zlcm5zIGFsbG9jYXRpb24gb2Ygd2lyZWxlc3MgcmFkaW8gcmVzb3VyY2VzIGJldHdl ZW4gcHVibGljIGFuZCBXUFMNCmNhbGxzLiAgVGhlIGN1cnJlbnQgZGVmYXVsdCByZXNlcnZlcyBz ZXZlcmFsIHRpbWVzIG1vcmUgY2FwYWNpdHkgZm9yIHRoZQ0KcHVibGljIHRoYW4gZm9yIHVzZXJz IG9mIHRoZSBwcmlvcml0eSBzZXJ2aWNlLiAgRXh0ZW5zaXZlIG1vZGVsaW5nIGFuZA0KYW5hbHlz aXMgaGF2ZSBiZWVuIHBlcmZvcm1lZCB0byBwcmVkaWN0IHRoZSBhZGVxdWFjeSBvZiB0aGUgZmVh dHVyZS4gIFRoZQ0KcmVzdWx0cyBzaG93IGluc2lnbmlmaWNhbnQgaW1wYWN0IG9mIFdQUyB0cmFm ZmljIG9uIHRoZSBwdWJsaWMgaW4gYQ0Kc3BlY3RydW0gb2YgcGxhdXNpYmxlIGNvbmdlc3Rpb24g c2NlbmFyaW9zLg0KDQpIb3BlIHRoYXQgaGVscHMuDQoNCkRlbm5pcw0KDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGhpcyBpcyBhIFBSSVZBVEUgbWVzc2FnZS4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlDQpkZWxldGUgd2l0aG91dCBj b3B5aW5nIGFuZCBraW5kbHkgYWR2aXNlIHVzIGJ5IGUtbWFpbCBvZiB0aGUgbWlzdGFrZSBpbg0K ZGVsaXZlcnkuIE5PVEU6IFJlZ2FyZGxlc3Mgb2YgY29udGVudCwgdGhpcyBlLW1haWwgc2hhbGwg bm90IG9wZXJhdGUgdG8NCmJpbmQgQ1NDIHRvIGFueSBvcmRlciBvciBvdGhlciBjb250cmFjdCB1 bmxlc3MgcHVyc3VhbnQgdG8gZXhwbGljaXQgd3JpdHRlbg0KYWdyZWVtZW50IG9yIGdvdmVybm1l bnQgaW5pdGlhdGl2ZSBleHByZXNzbHkgcGVybWl0dGluZyB0aGUgdXNlIG9mIGUtbWFpbA0KZm9y IHN1Y2ggcHVycG9zZS4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoNCg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgIkphc29uIE1pY2hh ZWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAg ICAgICAgICAgICBDYW5vbiIgPGZpYXRsdXggICAgICAgICAgVG86ICAgICAgIkphc29uIE1pY2hh ZWwgQ2Fub24iIDxmaWF0bHV4QGFkZWxwaGlhLm5ldD4sICJLaW5nLCBLaW1iZXJseSBTLiIgICAg ICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgIEBhZGVscGhpYS5uZXQ+ICAgICAgICAg ICA8S0lNQkVSTFkuUy5LSU5HQHNhaWMuY29tPiwgSmFuZXQgUCBHdW5uL0ZFRC9DU0NAQ1NDICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAg U2VudCBieTogICAgICAgICAgICAgICAgIGNjOiAgICAgIGllcHJlcC1ib3VuY2VzQGlldGYub3Jn LCBqb24ucGV0ZXJzb25AbmV1c3Rhci5iaXosIGllcHJlcEBpZXRmLm9yZywgICAgICAgICAgICAN CiAgICAgICAgICAgICAgICAgICAgICBpZXByZXAtYm91bmNlcyAgICAgICAgICAgc29iQGhhcnZh cmQuZWR1ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBTdWJqZWN0OiBSZTogW0llcHJlcF0gUmUtY2hhcnRlcj8gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAwNy8wMS8yMDA1IDA0OjU4ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAg IFBNICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNCg0KDQpT b3JyeSwgSSBtZWFudCBHRVRTL1dQUyBhbmQgTUxQUC4NCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2Fn ZSAtLS0tLQ0KRnJvbTogIkphc29uIE1pY2hhZWwgQ2Fub24iIDxmaWF0bHV4QGFkZWxwaGlhLm5l dD4NClRvOiAiS2luZywgS2ltYmVybHkgUy4iIDxLSU1CRVJMWS5TLktJTkdAc2FpYy5jb20+OyAi SmFuZXQgUCBHdW5uIg0KPGpndW5uNkBjc2MuY29tPg0KQ2M6IDxpZXByZXAtYm91bmNlc0BpZXRm Lm9yZz47IDxpZXByZXBAaWV0Zi5vcmc+Ow0KPGpvbi5wZXRlcnNvbkBuZXVzdGFyLmJpej47IDxz b2JAaGFydmFyZC5lZHU+DQpTZW50OiBGcmlkYXksIEp1bHkgMDEsIDIwMDUgNDo1NCBQTQ0KU3Vi amVjdDogUmU6IFtJZXByZXBdIFJlLWNoYXJ0ZXI/DQoNCg0KSSBoYXZlIGEgZ2VuZXJpYywgaGln aCBsZXZlbCBxdWVzdGlvbi4NCg0KQXMgYSBjaXZpbGlhbiBpbiBhbiBlbWVyZ2VuY3kgc2l0dWF0 aW9uIEkgY2FsbCA5LTEtMSB0byByZXBvcnQgc29tZSBsaWZlDQp0aHJlYXRlbmluZyBzaXR1YXRp b24gaW4gbXkNCmhvdXNlLiAgV2hpbGUgdGhlIGNhbGwgaXMgaW4gcHJvZ3Jlc3MgYSBzdWZmaWNp ZW50IG51bWJlciBvZiBnb3Zlcm5tZW50DQpvZmZpY2lhbHMgZXZva2UgYSBHRVRTL1dBUw0Kb3Ig TU9QIGNhcGFiaWxpdHkgYW5kIG15IGNhbGwgaXMgZWZmZWN0aXZlbHkgcHJlZW1wdGVkIG9yIGRl Z3JhZGVkIHRvIGENCmxldmVsIHRoYXQgaXMgbm90IHRvbGVyYWJsZS4NCk15IHF1ZXN0aW9uIGlz IGRpZCBhIHB1YmxpYyBwb2xpY3kgZGViYXRlIHJlc3VsdCBpbiBhIENvbmdyZXNzaW9uYWwgbGF3 IG9yDQpGQ0MgUmVndWxhdGlvbiB0aGF0IHBlcm1pdHMNCnRoZSBJVEVNIHRvIGNyYWZ0IGVuYWJs aW5nIHRlY2hub2xvZ3k/ICBJZiBzbywgYSByZWZlcmVuY2UgdG8gdGhlIGRvY3VtZW50DQp3b3Vs ZCBiZSBncmVhdGx5DQphcHByZWNpYXRlZC4NCg0KVGhhbmtzLA0KSmFzb24NCg0KLS0tLS0gT3Jp Z2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogIkphbmV0IFAgR3VubiIgPGpndW5uNkBjc2MuY29t Pg0KVG86ICJLaW5nLCBLaW1iZXJseSBTLiIgPEtJTUJFUkxZLlMuS0lOR0BzYWljLmNvbT4NCkNj OiA8aWVwcmVwLWJvdW5jZXNAaWV0Zi5vcmc+OyA8am9uLnBldGVyc29uQG5ldXN0YXIuYml6PjsN CjxpZXByZXBAaWV0Zi5vcmc+OyA8c29iQGhhcnZhcmQuZWR1Pg0KU2VudDogRnJpZGF5LCBKdWx5 IDAxLCAyMDA1IDQ6MDEgUE0NClN1YmplY3Q6IFJlOiBbSWVwcmVwXSBSZS1jaGFydGVyPw0KDQoN Cj4NCj4NCj4NCj4NCj4gSSBoYXZlIGEgZ2VuZXJpYywgaGlnaCBsZXZlbCBjb21tZW50Lg0KPg0K PiBJZiB3ZSBhcmUgZXh0ZW5kaW5nIHRoZSBjaGFydGVyIGZyb20g4oCccmVxdWlyZW1lbnRzIG9u bHnigJ0gdG8g4oCccmVxdWlyZW1lbnRzDQo+IGFuZCBzb2x1dGlvbnMgd2hlcmUgbm90IGNvdmVy ZWQgZWxzZXdoZXJl4oCdLCAgSSB0aGluayB0aGUgc29sdXRpb24gc3BhY2UNCj4gc2hvdWxkIGlu Y2x1ZGUgc29sdXRpb25zIGZvciDigJx0aGUgZXZvbHV0aW9uIG9mIEdFVFMvV1BTIHRvIElQ4oCd IGFzIHdlbGwgYXMNCj4gc29sdXRpb25zIGZvciDigJx0aGUgZXZvbHV0aW9uIG9mIE1MUFAgdG8g SVDigJ0uDQo+DQo+IFNpbWlsYXJseSwgdGhlIHJlcXVpcmVtZW50cyBhbmQgZnJhbWV3b3JrcyB0 aGF0IGhhdmUgYmVlbiBwcmV2aW91c2x5DQo+IHByb2R1Y2VkIGNvdmVyIHRoZSBlbnRpcmUgSUVQ UkVQIHNjb3BlLCBib3RoICJzb3J0IG9mIGxpa2UgTUxQUCIgYW5kDQoic29ydA0KPiBvZiBsaWtl IEdFVFMiLiAgU28gSSB0aGluayBpdCB3b3VsZCBiZSBhcHByb3ByaWF0ZSB0byBoYXZlIGRlbGl2 ZXJhYmxlcw0KPiBzdWNoIGFzDQo+ICJFbWVyZ2VuY3kgVGhyZWF0cyBBbmFseXNpcyBmb3IgQ29t bWVyY2lhbC9QdWJsaWMgTmV0d29ya3MiDQo+ICJSZXF1aXJlbWVudHMgZm9yIEVtZXJnZW5jeSBQ cmVwYXJlZG5lc3MgaW4gQ29tbWVyY2lhbC9QdWJsaWMgTmV0d29ya3MiDQo+ICJQb3RlbnRpYWwg U29sdXRpb25zIGZvciBDb21tZXJjaWFsL1B1YmxpYyBOZXR3b3JrcyINCj4gIk1lY2hhbmlzbXMg dG8gYmUgVXNlZCBieSBDb21tZXJjaWFsL1B1YmxpYyBOZXR3b3JrcyINCj4gYXMgd2VsbCBhcyB0 aGUgb25lcyBwcm9wb3NlZCBmb3IgIkdvdmVybm1lbnQvTWlsaXRhcnkgTmV0d29ya3MiLg0KPg0K PiBJIHRoaW5rIHRoYXQgd291bGQgYmUgbW9yZSB1c2VmdWwgdGhhbiAiRGlmZmVyZW5jZXMgYmV0 d2VlbiBHRVRTIGFuZCBNTFBQDQo+IG5ldHdvcmtzIiwgZXNwZWNpYWxseSBzaW5jZSBzb21lIG9m IHRoZSBkaWZmZXJlbmNlcyB3aGljaCBhcmUgc2lnbmlmaWNhbnQNCj4gaW4gdGhlIGNpcmN1aXQg c3dpdGNoZWQgd29ybGQgbWF5IGJlIGxlc3Mgc2lnbmlmaWNhbnQgaW4gdGhlIHBhY2tldA0KPiBz d2l0Y2hlZCB3b3JsZC4gIEJ1dCBtYXliZSBpZiBJIHNhdyBhbiBhYnN0cmFjdCBvZiB3aGF0IHdh cyBpbnRlbmRlZCBmb3INCj4gdGhlIGRvY3VtZW50LCBJIHdvdWxkIGNoYW5nZSBteSBtaW5kLg0K Pg0KPiBKYW5ldA0KPg0KPg0KPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo+ DQo+IFRoaXMgaXMgYSBQUklWQVRFIG1lc3NhZ2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQsIHBsZWFzZQ0KPiBkZWxldGUgd2l0aG91dCBjb3B5aW5nIGFuZCBraW5kbHkg YWR2aXNlIHVzIGJ5IGUtbWFpbCBvZiB0aGUgbWlzdGFrZSBpbg0KPiBkZWxpdmVyeS4gTk9URTog UmVnYXJkbGVzcyBvZiBjb250ZW50LCB0aGlzIGUtbWFpbCBzaGFsbCBub3Qgb3BlcmF0ZSB0bw0K PiBiaW5kIENTQyB0byBhbnkgb3JkZXIgb3Igb3RoZXIgY29udHJhY3QgdW5sZXNzIHB1cnN1YW50 IHRvIGV4cGxpY2l0DQo+IHdyaXR0ZW4NCj4gYWdyZWVtZW50IG9yIGdvdmVybm1lbnQgaW5pdGlh dGl2ZSBleHByZXNzbHkgcGVybWl0dGluZyB0aGUgdXNlIG9mIGUtbWFpbA0KPiBmb3Igc3VjaCBw dXJwb3NlLg0KPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo+DQo+DQo+DQo+ DQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICJLaW5nLCBLaW1iZXJseQ0KPiAgICAgICAgICAg ICAgICAgICAgICBTLiIgICAgICAgICAgICAgICAgICAgICAgVG86ICAgICAgIkllcHJlcA0KPiAo aWVwcmVwQGlldGYub3JnKSIgPGllcHJlcEBpZXRmLm9yZz4NCj4gICAgICAgICAgICAgICAgICAg ICAgPEtJTUJFUkxZLlMuS0lORyAgICAgICAgIGNjOiAgICAgIHNvYkBoYXJ2YXJkLmVkdSwNCj4g IkpvbiBQZXRlcnNvbiBcKGpvbi5wZXRlcnNvbkBuZXVzdGFyLmJpelwpIg0KPiAgICAgICAgICAg ICAgICAgICAgICBAc2FpYy5jb20+ICAgICAgICAgICAgICAgPGpvbi5wZXRlcnNvbkBuZXVzdGFy LmJpej4NCj4gICAgICAgICAgICAgICAgICAgICAgU2VudCBieTogICAgICAgICAgICAgICAgIFN1 YmplY3Q6IFtJZXByZXBdDQo+IFJlLWNoYXJ0ZXI/DQo+ICAgICAgICAgICAgICAgICAgICAgIGll cHJlcC1ib3VuY2VzDQo+DQo+DQo+ICAgICAgICAgICAgICAgICAgICAgIDA2LzMwLzIwMDUgMTA6 MjQNCj4gICAgICAgICAgICAgICAgICAgICAgQU0NCj4NCj4NCj4NCj4NCj4NCj4NCj4gU2NvdHQg YW5kIEkgaGF2ZSBhc2tlZCBmb3IgYSAxIGhvdXIgbWVldGluZyBzbG90IGF0DQo+IHRoZSBQYXJp cyBJRVRGIG1lZXRpbmcgdG8gZGlzY3VzcyBhIHBvc3NpYmxlIHJlLWNoYXJ0ZXINCj4gb2YgaWVw cmVwLiAgQSBwcm92aXNpb25hbCBuZXcgY2hhcnRlciBpcyBpbmNsdWRlZCBiZWxvdy4NCj4NCj4g S2ltYmVybHkNCj4NCj4NCj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioNCj4gRHJhZnQgcmV2aXNpb24NCj4gSW50ZXJuZXQgRW1lcmdlbmN5IFByZXBhcmVkbmVzcyAo aWVwcmVwKSBDaGFydGVyDQo+DQo+IERlc2NyaXB0aW9uIG9mIFdvcmtpbmcgR3JvdXA6DQo+DQo+ IEVmZmVjdGl2ZSB0ZWxlY29tbXVuaWNhdGlvbnMgY2FwYWJpbGl0aWVzIGFyZSBpbXBlcmF0aXZl IHRvDQo+IGZhY2lsaXRhdGUgaW1tZWRpYXRlIHJlY292ZXJ5IG9wZXJhdGlvbnMgZm9yIHNlcmlv dXMNCj4gZGlzYXN0ZXIgZXZlbnRzIGluY2x1ZGluZyBuYXR1cmFsIGRpc2FzdGVycyAoZS5nLiwN Cj4gaHVycmljYW5lcywgZmxvb2RzLCBlYXJ0aHF1YWtlcykgYW5kIHRob3NlIGNyZWF0ZWQgYnkg bWFuDQo+IChlLmcuLCB0ZXJyb3Jpc3QgYXR0YWNrcywgY29tYmF0IHNpdHVhdGlvbnMgb3Igd2Fy dGltZQ0KPiBldmVudHMpLiAgSW4gYWRkaXRpb24sIHJlbGF0ZWQgY2FwYWJpbGl0aWVzIHNob3Vs ZCBiZSB1c2FibGUNCj4gaW4gbm9ybWFsIGNvbW1hbmQgYW5kIGNvbnRyb2wgb3BlcmF0aW9ucyBv ZiBtaWxpdGFyeQ0KPiBzZXJ2aWNlcywgd2hpY2ggb2Z0ZW4gaGF2ZSB0aW1lbGluZXNzIHJlcXVp cmVtZW50cyBldmVuIGluDQo+IHBlYWNldGltZS4gIFRoZSBJRVBSRVAgV0cgd2lsbCBhZGRyZXNz IHByb2FjdGl2ZSBhbmQNCj4gcmVhY3RpdmUgcm9idXN0bmVzcyBhbmQgcmVjb3ZlcnkgZnJvbSB2 YXJpb3VzIG91dGFnZXMgdXNpbmcNCj4gdGhyZWUgcGVyc3BlY3RpdmVzOg0KPg0KPiAxLiBBIGNv bW1lcmNpYWwgKGkuZS4sIG9yIHB1YmxpYykgdGVsZWNvbW11bmljYXRpb25zDQo+IGluZnJhc3Ry dWN0dXJlDQo+DQo+IDIuIEEgZ292ZXJubWVudGFsL21pbGl0YXJ5IHRlbGVjb21tdW5pY2F0aW9u cyBpbmZyYXN0cnVjdHVyZQ0KPiB0aGF0IG1heSByZXRhaW5zIHNvbGUgb3duZXJzaGlwIGFuZCBh ZG1pbmlzdHJhdGlvbiBvZiBpdHMNCj4gb3duIHJlc291cmNlcw0KPg0KPiAzLiBBIGdvdmVybm1l bnRhbC9taWxpdGFyeSB0ZWxlY29tbXVuaWNhdGlvbnMgaW5mcmFzdHJ1Y3R1cmUNCj4gdGhhdCBj b21iaW5lcyBwcml2YXRlIHJlc291cmNlcyBhbmQgbGV2ZXJhZ2VzIHB1YmxpYw0KPiBpbmZyYXN0 cnVjdHVyZS4gIFRoaXMgc2NlbmFyaW8gbWF5IGJlIHN1YmplY3QgdG8gbG9jYWwNCj4gcG9saWNp ZXMsIGxhd3MsIGFuZCByZWd1bGF0aW9ucy4NCj4NCj4gRGlzYXN0ZXJzIGNhbiBoYXBwZW4gYW55 IHRpbWUsIGFueSBwbGFjZSwgdW5leHBlY3RlZGx5Lg0KPiBRdWljayByZXNwb25zZSBmb3IgcmVj b3Zlcnkgb3BlcmF0aW9ucyByZXF1aXJlcyBpbW1lZGlhdGUNCj4gYWNjZXNzIHRvIGFueSBwdWJs aWMgdGVsZWNvbW11bmljYXRpb25zIGNhcGFiaWxpdGllcyBhdA0KPiBoYW5kLiBUaGVzZSBjYXBh YmlsaXRpZXMgaW5jbHVkZTogY29udmVudGlvbmFsIHRlbGVwaG9uZSwNCj4gY2VsbHVsYXIgcGhv bmVzLCBhbmQgSW50ZXJuZXQgYWNjZXNzIHZpYSBvbmxpbmUgdGVybWluYWxzLA0KPiBJUCB0ZWxl cGhvbmVzLCBhbmQgd2lyZWxlc3MgUERBcy4gVGhlIGNvbW1lcmNpYWwNCj4gdGVsZWNvbW11bmlj YXRpb25zIGluZnJhc3RydWN0dXJlIGlzIHJhcGlkbHkgZXZvbHZpbmcgdG8NCj4gSW50ZXJuZXQt YmFzZWQgdGVjaG5vbG9neS4gIFRoZXJlZm9yZSwgdGhlIEludGVybmV0DQo+IGNvbW11bml0eSBu ZWVkcyB0byBjb25zaWRlciBob3cgaXQgY2FuIGJlc3Qgc3VwcG9ydA0KPiBlbWVyZ2VuY3kgbWFu YWdlbWVudCBhbmQgcmVjb3Zlcnkgb3BlcmF0aW9ucy4NCj4NCj4gUG90ZW50aWFsIGRpc2FzdGVy cyBmb3IgZ292ZXJubWVudGFsL21pbGl0YXJ5DQo+IGluZnJhc3RydWN0dXJlcyBjYW4gZXh0ZW5k IGJleW9uZCB3aGF0IG1pZ2h0IGJlIGV4cGVyaWVuY2VkDQo+IGJ5IHRoZSBjb21tZXJjaWFsL3B1 YmxpYyBzZWN0b3IgYW5kIGNhbiBiZSBhbnRpY2lwYXRlZCB0bw0KPiBzb21lIGRlZ3JlZS4gIFRo dXMsIHByb2FjdGl2ZSBtZWNoYW5pc21zIHRvIGFkZHJlc3Mgd291bGQtYmUNCj4gb3V0YWdlcyBh cmUgcmVxdWlyZWQgZm9yIHRoZXNlIHNjZW5hcmlvcy4NCj4NCj4gVGhlIElFUFJFUCBXRyB3aWxs IHdvcmsgb24gdGhlc2UgdGhyZWUgcGVyc3BlY3RpdmVzDQo+IChjb21tZXJjaWFsLCBnb3Zlcm5t ZW50YWwvbWlsaXRhcnksIGFuZCB0aGUgY29tYmluYXRpb24pIGFuZA0KPiBzeW5lcmdpemUgY29t bW9uIG1lY2hhbmlzbXMgYW5kIHJlcXVpcmVtZW50cyBpbnRvIG90aGVyDQo+IGdyb3VwcyB3aGVy ZSBwb3NzaWJsZSwgd2hpbGUgbWFpbnRhaW5pbmcgYSBzZXBhcmF0ZSB0cmFjayBvZg0KPiBJRVBS RVAgZG9jdW1lbnRzIGZvciB0aGUgdW5pcXVlIG1lY2hhbmlzbXMgYW5kIHJlcXVpcmVtZW50cw0K PiBvZiBlYWNoIHBlcnNwZWN0aXZlcy4NCj4NCj4gTm93IHRoYXQgdGhlIGluaXRpYWwgZG9jdW1l bnRzIGRlc2NyaWJlIHRoZSBicm9hZCBwcm9ibGVtDQo+IHNwYWNlIGFuZCBpdHMgc2FsaWVudCBj aGFyYWN0ZXJpc3RpY3MsIG5ldyBlZmZvcnRzIHdpbGwNCj4gZm9jdXMgb24gc3BlY2lmaWMgcmVx dWlyZW1lbnRzIGFuZCBzb2x1dGlvbnMgc3VjaCBhcyB0aG9zZQ0KPiBwZXJ0YWluaW5nIHRvIHRo ZSBnb3Zlcm5tZW50YWwvbWlsaXRhcnkgc2VjdG9yLiAgT25lDQo+IGRvY3VtZW50IGV4aXN0cyBp biB0aGUgVHJhbnNwb3J0IEFyZWEgd29ya2luZyBncm91cCBvZg0KPiBpbnRlcmVzdCB0byBJRVBS RVAgdGhhdCBjb3VsZCBzYXRpc2Z5IGEgZ292ZXJubWVudGFsDQo+IGZyYW1ld29yay9CQ1AgaXMg ZHJhZnQtaWV0Zi10c3Z3Zy1tbHBwLXRoYXQtd29ya3MtWFguICBUaGlzDQo+IGRvY3VtZW50IHdp bGwgcHJvZ3Jlc3MgdG8gY29tcGxldGlvbiBpbiB0aGF0IFdHLCB5ZXQgYmUgdGhlDQo+IGJhc2lz IG9mIG1vcmUgd29yayBpbiB0aGlzIElFUFJFUCBXRy4gIFNvbWUgYWRkaXRpb25hbA0KPiBlZmZv cnRzIG9uIHRoZSBnb3Zlcm5tZW50YWwvbWlsaXRhcnkgdHJhY2sgd2l0aGluIElFUFJFUA0KPiB3 aWxsIGZvY3VzIG9uIHRoaXMgVFNWV0cgZG9jdW1lbnQsIGFuYWx5emUgZ2FwcywgYW5kIHByb3Zp ZGUNCj4gaW5wdXQgd2hlcmUgbmVlZGVkLg0KPg0KPiBUaGUgZm9sbG93aW5nIGFyZSBmb3VyIHNw ZWNpZmljIGV4YW1wbGVzIHRoYXQgY2FuIHNhdGlzZnkNCj4gdGhlIGludGVyZXN0cyBvZiBnb3Zl cm5tZW50YWwvbWlsaXRhcnkgKGFuZCBwb3RlbnRpYWxseSwNCj4gY29tbWVyY2lhbC9wdWJsaWMp IGVtZXJnZW5jeSBjb21tdW5pY2F0aW9uczoNCj4NCj4gMS4gQ29udmV5aW5nIGluZm9ybWF0aW9u IGFib3V0IHRoZSBwcmlvcml0eSBvZiBzcGVjaWZpYw0KPiBmbG93cyAob3Igc2Vzc2lvbnMpIHRo YXQgb3JpZ2luYXRlIGluIGEgVm9JUCBlbnZpcm9ubWVudC4NCj4gVGhpcyBjb3VsZCBpbmNsdWRl IGEgcmVxdWlyZW1lbnRzIGVmZm9ydCB0byBkZXNjcmliZQ0KPiBleHRlbnNpb25zIHRvIE5TSVMg b3IgUlNWUC4gUmVxdWlyZW1lbnRzIGZvciBOU0lTIHdvdWxkIGJlDQo+IGZvcndhcmRlZCB0byB0 aGUgTlNJUyB3b3JraW5nIGdyb3VwLiBSZXF1aXJlbWVudHMgZm9yIFJTVlANCj4gY291bGQgYmUg Zm9yd2FyZGVkIHRvIHRzdndnIG9yIHdvcmtlZCBvbiBpbiBJRVBSRVAuDQo+DQo+IDIuIE5lc3Rl ZCBWUE5zIHJlcXVpcmUgc3BlY2lhbCBjb25zaWRlcmF0aW9ucyBmb3Igcm91dGluZw0KPiBhbmQg UW9TIGlmIG5vZGVzIGluIHRoZSBwYXRoIHRoYXQgbWFrZSB0aGVzZSBkZWNpc2lvbnMNCj4gZ2Vu ZXJhbGx5IGhhdmUgbGltaXRlZCBpbmZvcm1hdGlvbi4NCj4NCj4gMy4gU29tZSBjb3VudHJpZXMg cmVxdWlyZSBjaXZpbCBuZXR3b3JrcyB0byBwcmVlbXB0IHNlc3Npb25zDQo+IHVuZGVyIHN0YXRl IGNpcmN1bXN0YW5jZXMsIGFuZCBwcmVlbXB0aW9uIGlzIGNvbnNpZGVyZWQgYW4NCj4gYWJzb2x1 dGUgcmVxdWlyZW1lbnQgaW4gZ292ZXJubWVudGFsIG5ldHdvcmtzIGluIG1vc3QNCj4gY291bnRy aWVzLiBVbmxlc3MgaW1wbGVtZW50YXRpb24gb2YgdGhlc2UgcmVxdWlyZW1lbnRzIGNhbg0KPiBi ZSBvYmplY3RpdmVseSBzaG93biB0byB0aHJlYXRlbiBuZXR3b3JrIGhlYWx0aCAodmlhDQo+IHNp bXVsYXRpb24gb3IgaW4gb3BlcmF0aW9ucyksIHRoZW4gdGhlIHJlcXVpcmVtZW50IG5lZWRzIHRv DQo+IGJlIGNvbnNpZGVyZWQgYnkgSUVQUkVQIGFuZCBzcGVjaWZpYyBzb2x1dGlvbnMgbXVzdCBi ZQ0KPiBkZXZlbG9wZWQuDQo+DQo+IDQuIE5vbi1yZWFsLXRpbWUgYXBwbGljYXRpb25zIHJlcXVp cmUgbWVhc3VyZXMgb2YgUW9TIGFuZA0KPiBvdGhlciBwcmVmZXJlbnRpYWwgdHJlYXRtZW50cywg YXMgdm9pY2Ugd2lsbCBub3QgYmUgdGhlIG9ubHkNCj4gYXBwbGljYXRpb24gdXNlZCBieSBJRVBS RVAuDQo+DQo+IEluIHRoZSBJRVRGLCBjb25zaWRlcmF0aW9ucyBmb3IgdHJlYXRtZW50IGFuZCBz ZWN1cml0eSBvZg0KPiBlbWVyZ2VuY3kgY29tbXVuaWNhdGlvbnMgc3RyZXRjaCBhY3Jvc3MgYSBu dW1iZXIgb2YgQXJlYXMNCj4gYW5kIFdvcmtpbmcgR3JvdXBzLCBub3RhYmx5IGluY2x1ZGluZyB0 aGUgdmFyaW91cyB0ZWxlcGhvbnkNCj4gc2lnbmFsaW5nIHdvcmtpbmcgZ3JvdXBzLCBQcm90b2Nv bCBmb3IgY2FycnlpbmcNCj4gQXV0aGVudGljYXRpb24gZm9yIE5ldHdvcmsgQWNjZXNzIChwYW5h KSwgdGhlIG9wZW4gVHJhbnNwb3J0DQo+IEFyZWEgZm9yIHBhdGgtY291cGxlZCBzaWduYWxpbmcg YW5kIHZhcmlvdXMgb3BlcmF0aW9uYWwNCj4gZ3JvdXBzLiBJRVBSRVAgd2lsbCBjb29wZXJhdGUg Y2xvc2VseSB3aXRoIHRoZXNlIGdyb3VwcyBhbmQNCj4gd2l0aCB0aG9zZSBvdXRzaWRlIG9mIHRo ZSBJRVRGIHN1Y2ggYXMgdmFyaW91cyBJVFUtVCBzdHVkeQ0KPiBncm91cHMuDQo+DQo+DQo+IElm IHRoZXJlIGlzIGFuIGV4aXN0aW5nIFdHIHRoYXQgY2FuIGRpc2N1c3MgdGhlIHJlcXVpcmVtZW50 cw0KPiBmb3IgZXh0ZW5kaW5nIHRoZWlyIHByb3RvY29sIG9yIG1lY2hhbmlzbSwgSUVQUkVQIHdp bGwNCj4gZ2VuZXJhdGUgb25seSBhIHJlcXVpcmVtZW50cyBkb2N1bWVudCBmb3IgdGhhdCBncm91 cCB0bw0KPiBkaXNjdXNzLg0KPg0KPiBJZiB0aGVyZSBpcyBub3QgYW4gZXhpc3RpbmcgV0cgdGhh dCBjYW4gZGlzY3VzcyB0aGUNCj4gcmVxdWlyZW1lbnRzIGZvciBleHRlbmRpbmcgdGhlaXIgcHJv dG9jb2wgb3IgbWVjaGFuaXNtLA0KPiBJRVBSRVAgd2lsbCBwcmVwYXJlIHJlcXVpcmVtZW50cyBh bmQgZGlzY3VzcyB0aGUgZXh0ZW5zaW9uDQo+IG9mIHRoYXQgcHJvdG9jb2wvbWVjaGFuaXNtIG9y IHByb3RvY29scy9tZWNoYW5pc21zIHdpdGhpbg0KPiBJRVBSRVAuDQo+DQo+DQo+IEdvYWxzIGFu ZCBNaWxlc3RvbmVzOg0KPg0KPiBEb25lICAgU3VibWl0IGluaXRpYWwgSS1EIG9mIFJlcXVpcmVt ZW50cw0KPg0KPiBEb25lICAgU3VibWl0IGluaXRpYWwgSS1EIG9mIEZyYW1ld29yaw0KPg0KPiBE b25lICAgU3VibWl0IGluaXRpYWwgSS1EIG9mIFJlY29tbWVuZGF0aW9ucyBCQ1ANCj4NCj4gRG9u ZSAgIFN1Ym1pdCBSZXF1aXJlbWVudHMgSS1EIHRvIElFU0cgZm9yIHB1YmxpY2F0aW9uIGFzIGFu DQo+ICAgICAgIEluZm9ybWF0aW9uYWwgUkZDDQo+DQo+IERvbmUgICBTdWJtaXQgRnJhbWV3b3Jr IEktRCB0byBJRVNHIGZvciBwdWJsaWNhdGlvbiBhcyBhbg0KPiBJbmZvcm1hdGlvbmFsIFJGQw0K Pg0KPiBEZWMgMDMgU3VibWl0IFJlY29tbWVuZGF0aW9ucyBJLUQgdG8gSUVTRyBmb3IgcHVibGlj YXRpb24gYXMNCj4gYSBCQ1ANCj4NCj4gT2N0IDA1IFN1Ym1pdCBhbiBpbml0aWFsIEktRCBvZiBF bWVyZ2VuY3kgVGhyZWF0cyBBbmFseXNpcw0KPiBvZiBHb3Zlcm5tZW50L01pbGl0YXJ5IE5ldHdv cmtzDQo+DQo+IERlYyAwNSBTdWJtaXQgYW4gaW5pdGlhbCBJLUQgb2YgRGlmZmVyZW5jZXMgYmV0 d2VlbiBHRVRTIGFuZA0KPiBNTFBQIE5ldHdvcmtzDQo+DQo+IEZlYiAwNiBTdWJtaXQgYW4gaW5p dGlhbCBJLUQgb2YgUmVxdWlyZW1lbnRzIG9mDQo+IEdvdmVybm1lbnQvTWlsaXRhcnkgTmV0d29y a3MNCj4NCj4gTWFyIDA2IFN1Ym1pdCBhbiBpbml0aWFsIEktRCBvZiBDb25zaWRlcmF0aW9ucyBm b3IgcG90ZW50aWFsDQo+IHNvbHV0aW9ucyBvZiBHb3Zlcm5tZW50L01pbGl0YXJ5IE5ldHdvcmtz DQo+DQo+IEFwciAwNiBTdWJtaXQgYW4gaW5pdGlhbCBJLUQgb2YgTWVjaGFuaXNtcyB0byBiZSB1 c2VkIGJ5DQo+ICAgICAgIEdvdmVybm1lbnQvTWlsaXRhcnkgTmV0d29ya3MNCj4NCj4gT2N0IDA1 IFN1Ym1pdCBmaW5hbCBJLUQgb2YgRW1lcmdlbmN5IFRocmVhdHMgQW5hbHlzaXMgb2YNCj4gICAg ICAgR292ZXJubWVudC9NaWxpdGFyeSBOZXR3b3JrcyB0byBJRVNHIGFzIEluZm9ybWF0aW9uYWwN Cj4gUkZDDQo+DQo+IEZlYiAwNiBTdWJtaXQgZmluYWwgSS1EIG9mIFJlcXVpcmVtZW50cyBvZg0K PiBHb3Zlcm5tZW50L01pbGl0YXJ5IE5ldHdvcmtzIHRvIElFU0cgYXMgSW5mb3JtYXRpb25hbCBS RkMNCj4NCj4gQXByIDA2IFN1Ym1pdCBmaW5hbCBJLUQgb2YgTWVjaGFuaXNtcyB0byBiZSB1c2Vk IGJ5DQo+ICAgICAgIEdvdmVybm1lbnQvTWlsaXRhcnkgTmV0d29ya3MgdG8gSUVTRyBhcyBCQ1Ag UkZDDQo+DQo+IFRoZSB3b3JraW5nIGdyb3VwIHdpbGwgZGlzY3VzcyByZS1jaGFydGVyaW5nIGlm IGFkZGl0aW9uYWwNCj4gZWZmb3J0cyBhcmUgYWdyZWVkIHVwb24gYnkgdGhlIFdHIChmb3IgZXhh bXBsZSwgd29yayBpdGVtcw0KPiByZWxhdGVkIHRvIHByb3RvY29scyBvdXRzaWRlIGV4aXN0aW5n IFdHcykuDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IEllcHJlcCBtYWlsaW5nIGxpc3QNCj4gSWVwcmVwQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2llcHJlcA0KPg0KDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQoNCg0KDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IEllcHJlcCBtYWlsaW5nIGxpc3QNCj4gSWVwcmVwQGlldGYub3JnDQo+ IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2llcHJlcA0KPg0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZXByZXAgbWFp bGluZyBsaXN0DQpJZXByZXBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2llcHJlcA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpJZXByZXAgbWFpbGluZyBsaXN0DQpJZXByZXBAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2llcHJlcA0KDQo= --===============1149788296== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep --===============1149788296==-- From ieprep-bounces@ietf.org Fri Jul 1 18:16:45 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00263 for ; Fri, 1 Jul 2005 18:16:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoUEZ-0004Ui-6u for ieprep-archive@ietf.org; Fri, 01 Jul 2005 18:43:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoToC-0001He-QE; Fri, 01 Jul 2005 18:16:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoToB-0001HT-IK; Fri, 01 Jul 2005 18:16: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 SAA00215; Fri, 1 Jul 2005 18:16:24 -0400 (EDT) Received: from seahorse.shentel.net ([204.111.11.44]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoUEE-0004Rr-5B; Fri, 01 Jul 2005 18:43:22 -0400 Received: from Steve (ha24s158.d.shentel.net [204.111.24.158]) by seahorse.shentel.net (8.12.11/8.12.11) with SMTP id j61MGCCo001558; Fri, 1 Jul 2005 18:16:13 -0400 From: "Steve Silverman" To: "Jason Michael Canon" , "King, Kimberly S." , "Janet P Gunn" Subject: RE: [Ieprep] Re-charter? Date: Fri, 1 Jul 2005 18:17:18 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <012b01c57e7f$911ed330$6401a8c0@canondownstairs> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Spam-Score: 3.7 (+++) X-Scan-Signature: 96e0f8497f38c15fbfc8f6f315bcdecb Content-Transfer-Encoding: quoted-printable Cc: ieprep-bounces@ietf.org, ieprep@ietf.org, jon.peterson@neustar.biz, sob@harvard.edu X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 3.7 (+++) X-Scan-Signature: 5b943e80df8c8cad631fd60298783617 Content-Transfer-Encoding: quoted-printable MLPP is not intended for the public network. If you're on the DoD = private network, the fact that you're using it means you have accepted the terms of service. Given the number of = high priority users, there is minimal impact on routine traffic.=20 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. So your 911 call would be equally unintelligible. = =20 Steve Silverman > -----Original Message----- > From: ieprep-bounces@ietf.org=20 > [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;=20 > ieprep@ietf.org; > sob@harvard.edu > Subject: Re: [Ieprep] Re-charter? >=20 >=20 > Sorry, I meant GETS/WPS and MLPP. >=20 > ----- Original Message -----=20 > From: "Jason Michael Canon" > To: "King, Kimberly S." ; "Janet P Gunn"=20 > > Cc: ; ;=20 > ; > Sent: Friday, July 01, 2005 4:54 PM > Subject: Re: [Ieprep] Re-charter? >=20 >=20 > I have a generic, high level question. >=20 > As a civilian in an emergency situation I call 9-1-1 to=20 > report some life > threatening situation in my > house. While the call is in progress a sufficient number=20 > of government > officials evoke a GETS/WAS > or MOP capability and my call is effectively preempted or=20 > degraded to a > level that is not tolerable. > My question is did a public policy debate result in a=20 > Congressional law or > FCC Regulation that permits > the ITEM to craft enabling technology? If so, a reference=20 > to the document > would be greatly > appreciated. >=20 > Thanks, > Jason >=20 > ----- Original Message -----=20 > From: "Janet P Gunn" > To: "King, Kimberly S." > Cc: ; ; > ; > Sent: Friday, July 01, 2005 4:01 PM > Subject: Re: [Ieprep] Re-charter? >=20 >=20 > > > > > > > > > > I have a generic, high level comment. > > > > If we are extending the charter from =E2=80=9Crequirements = only=E2=80=9D=20 > to =E2=80=9Crequirements > > and solutions where not covered elsewhere=E2=80=9D, I think the=20 > solution space > > should include solutions for =E2=80=9Cthe evolution of GETS/WPS=20 > to IP=E2=80=9D as well as > > solutions for =E2=80=9Cthe evolution of MLPP to IP=E2=80=9D. > > > > Similarly, the requirements and frameworks that have been=20 > previously > > produced cover the entire IEPREP scope, both "sort of=20 > like MLPP" and "sort > > of like GETS". So I think it would be appropriate to=20 > have deliverables > > such as > > "Emergency Threats Analysis for Commercial/Public Networks" > > "Requirements for Emergency Preparedness in=20 > 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=20 > between GETS and MLPP > > networks", especially since some of the differences which=20 > are significant > > in the circuit switched world may be less significant in=20 > the packet > > switched world. But maybe if I saw an abstract of what=20 > was intended for > > the document, I would change my mind. > > > > Janet > > > > > >=20 > ------------------------------------------------------------ > ---------------------------- > > > > This is a PRIVATE message. If you are not the intended=20 > recipient, please > > delete without copying and kindly advise us by e-mail of=20 > the mistake in > > delivery. NOTE: Regardless of content, this e-mail shall=20 > not operate to > > bind CSC to any order or other contract unless pursuant=20 > to explicit=20 > > written > > agreement or government initiative expressly permitting=20 > the use of e-mail > > for such purpose. > >=20 > ------------------------------------------------------------ > ---------------------------- > > > > > > > > > > > > "King, Kimberly > > S." To: "Ieprep=20 > > (ieprep@ietf.org)" > > sob@harvard.edu,=20 > > "Jon Peterson \(jon.peterson@neustar.biz\)" > > @saic.com> =20 > > > Sent by: Subject: [Ieprep]=20 > > 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 > > >=20 >=20 > ------------------------------------------------------------ > -------------------- >=20 >=20 > > _______________________________________________ > > Ieprep mailing list > > Ieprep@ietf.org > > https://www1.ietf.org/mailman/listinfo/ieprep > > >=20 >=20 > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep=20 >=20 >=20 > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep >=20 _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Tue Jul 5 09:18:48 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14319 for ; Tue, 5 Jul 2005 09:18:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dpnkp-0003b3-Fj for ieprep-archive@ietf.org; Tue, 05 Jul 2005 09:46:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpnIc-0005gX-5b; Tue, 05 Jul 2005 09:17:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpnI8-0005YP-U2 for ieprep@megatron.ietf.org; Tue, 05 Jul 2005 09:16:49 -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 JAA13167 for ; Tue, 5 Jul 2005 09:16:43 -0400 (EDT) Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dpnip-0002kD-Nk for ieprep@ietf.org; Tue, 05 Jul 2005 09:44:25 -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 j65DGYGd019590 for ; Tue, 5 Jul 2005 09:16:35 -0400 (EDT) In-Reply-To: Subject: Re: [Ieprep] Re-charter? To: "Ieprep (ieprep@ietf.org)" X-Mailer: Lotus Notes 652HF83 November 04, 2004 Message-ID: From: Janet P Gunn Date: Tue, 5 Jul 2005 09:14:43 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 07/05/2005 09:16:17 AM MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0061139100==" Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 --===============0061139100== Content-type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 DQoNCg0KDQpBcHBhcmVudGx5IHNvbWUgcGVvcGxlIHJlY2VpdmVkIGEgbWFuZ2xlZCB2ZXJzaW9u IG9mIHRoaXMsIHNvIEkgYW0NCnJlc2VuZGluZyBpdCBhdCBTY290dCdzIHJlcXVlc3QgKFNjb3R0 LCBsZXQgbWUga25vdyBpZiB0aGlzIGZpeGVkIGl0KQ0KSi4NCg0KSSBoYXZlIGEgZ2VuZXJpYywg aGlnaCBsZXZlbCBjb21tZW50Lg0KDQpJZiB3ZSBhcmUgZXh0ZW5kaW5nIHRoZSBjaGFydGVyIGZy b20g4oCccmVxdWlyZW1lbnRzIG9ubHnigJ0gdG8g4oCccmVxdWlyZW1lbnRzDQphbmQgc29sdXRp b25zIHdoZXJlIG5vdCBjb3ZlcmVkIGVsc2V3aGVyZeKAnSwgIEkgdGhpbmsgdGhlIHNvbHV0aW9u IHNwYWNlDQpzaG91bGQgaW5jbHVkZSBzb2x1dGlvbnMgZm9yIOKAnHRoZSBldm9sdXRpb24gb2Yg R0VUUy9XUFMgdG8gSVDigJ0gYXMgd2VsbCBhcw0Kc29sdXRpb25zIGZvciDigJx0aGUgZXZvbHV0 aW9uIG9mIE1MUFAgdG8gSVDigJ0uDQoNClNpbWlsYXJseSwgdGhlIHJlcXVpcmVtZW50cyBhbmQg ZnJhbWV3b3JrcyB0aGF0IGhhdmUgYmVlbiBwcmV2aW91c2x5DQpwcm9kdWNlZCBjb3ZlciB0aGUg ZW50aXJlIElFUFJFUCBzY29wZSwgYm90aCAic29ydCBvZiBsaWtlIE1MUFAiIGFuZCAic29ydA0K b2YgbGlrZSBHRVRTIi4gIFNvIEkgdGhpbmsgaXQgd291bGQgYmUgYXBwcm9wcmlhdGUgdG8gaGF2 ZSBkZWxpdmVyYWJsZXMNCnN1Y2ggYXMNCiAiRW1lcmdlbmN5IFRocmVhdHMgQW5hbHlzaXMgZm9y IENvbW1lcmNpYWwvUHVibGljIE5ldHdvcmtzIg0KICJSZXF1aXJlbWVudHMgZm9yIEVtZXJnZW5j eSBQcmVwYXJlZG5lc3MgaW4gQ29tbWVyY2lhbC9QdWJsaWMgTmV0d29ya3MiDQoiUG90ZW50aWFs IFNvbHV0aW9ucyBmb3IgQ29tbWVyY2lhbC9QdWJsaWMgTmV0d29ya3MiDQoiTWVjaGFuaXNtcyB0 byBiZSBVc2VkIGJ5IENvbW1lcmNpYWwvUHVibGljIE5ldHdvcmtzIg0KYXMgd2VsbCBhcyB0aGUg b25lcyBwcm9wb3NlZCBmb3IgIkdvdmVybm1lbnQvTWlsaXRhcnkgTmV0d29ya3MiLg0KDQpJIHRo aW5rIHRoYXQgd291bGQgYmUgbW9yZSB1c2VmdWwgdGhhbiAiRGlmZmVyZW5jZXMgYmV0d2VlbiBH RVRTIGFuZCBNTFBQDQpuZXR3b3JrcyIsIGVzcGVjaWFsbHkgc2luY2Ugc29tZSBvZiB0aGUgZGlm ZmVyZW5jZXMgd2hpY2ggYXJlIHNpZ25pZmljYW50DQppbiB0aGUgY2lyY3VpdCBzd2l0Y2hlZCB3 b3JsZCBtYXkgYmUgbGVzcyBzaWduaWZpY2FudCBpbiB0aGUgcGFja2V0DQpzd2l0Y2hlZCB3b3Js ZC4gIEJ1dCBtYXliZSBpZiBJIHNhdyBhbiBhYnN0cmFjdCBvZiB3aGF0IHdhcyBpbnRlbmRlZCBm b3INCnRoZSBkb2N1bWVudCwgSSB3b3VsZCBjaGFuZ2UgbXkgbWluZC4NCg0KSmFuZXQNCg0KDQoN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGhpcyBpcyBhIFBSSVZBVEUgbWVz c2FnZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlDQpkZWxl dGUgd2l0aG91dCBjb3B5aW5nIGFuZCBraW5kbHkgYWR2aXNlIHVzIGJ5IGUtbWFpbCBvZiB0aGUg bWlzdGFrZSBpbg0KZGVsaXZlcnkuIE5PVEU6IFJlZ2FyZGxlc3Mgb2YgY29udGVudCwgdGhpcyBl LW1haWwgc2hhbGwgbm90IG9wZXJhdGUgdG8NCmJpbmQgQ1NDIHRvIGFueSBvcmRlciBvciBvdGhl ciBjb250cmFjdCB1bmxlc3MgcHVyc3VhbnQgdG8gZXhwbGljaXQgd3JpdHRlbg0KYWdyZWVtZW50 IG9yIGdvdmVybm1lbnQgaW5pdGlhdGl2ZSBleHByZXNzbHkgcGVybWl0dGluZyB0aGUgdXNlIG9m IGUtbWFpbA0KZm9yIHN1Y2ggcHVycG9zZS4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCg== --===============0061139100== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep --===============0061139100==-- From ieprep-bounces@ietf.org Tue Jul 5 10:12:44 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18527 for ; Tue, 5 Jul 2005 09:26:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpnsB-0006fQ-5i for ieprep-archive@ietf.org; Tue, 05 Jul 2005 09:54:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpnFc-0004Im-R4; Tue, 05 Jul 2005 09:14:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpnFa-0004HM-DR for ieprep@megatron.ietf.org; Tue, 05 Jul 2005 09:14:10 -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 JAA11609 for ; Tue, 5 Jul 2005 09:14:07 -0400 (EDT) Received: from mailgw3a.lmco.com ([192.35.35.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpngG-0001i0-95 for ieprep@ietf.org; Tue, 05 Jul 2005 09:41:48 -0400 Received: from emss09g01.ems.lmco.com (relay6.ems.lmco.com [166.17.13.59]) by mailgw3a.lmco.com (8.12.10/8.12.10) with ESMTP id j65DDvG6016471; Tue, 5 Jul 2005 09:13:57 -0400 (EDT) Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1X6 #30875) id <0IJ500F01OR9KH@lmco.com>; Tue, 05 Jul 2005 09:13:57 -0400 (EDT) Received: from EMSS09I00.us.lmco.com ([158.183.26.31]) by lmco.com (PMDF V6.1-1X6 #30875) with ESMTP id <0IJ500BEQOR98O@lmco.com>; Tue, 05 Jul 2005 09:13:57 -0400 (EDT) Received: from EMSS04M14.us.lmco.com ([162.16.20.50]) by EMSS09I00.us.lmco.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 05 Jul 2005 09:13:57 -0400 Date: Tue, 05 Jul 2005 09:13:56 -0400 From: "Bose, Pratik" Subject: RE: [Ieprep] Re-charter? To: "King, Kimberly S." , ieprep@ietf.org Message-id: <37B6F612D86CA143B5F965E9EE8BD7AA0C0DFF98@emss04m14.us.lmco.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [Ieprep] Re-charter? Thread-Index: AcV9gCHRRBY9TvpDT0Cgz/evNr6ddgD4jiEw content-class: urn:content-classes:message X-OriginalArrivalTime: 05 Jul 2005 13:13:57.0255 (UTC) FILETIME=[66928170:01C58163] X-Spam-Score: 0.8 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Content-Transfer-Encoding: 7BIT Cc: sob@harvard.edu, jon.peterson@neustar.biz X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Content-Transfer-Encoding: 7BIT Hi, One important addition to the list of specific examples that comes to mind is: Extensions to Differentiated Services for a secure-authenticated environment: This category can include authentication for differentiated services, providing prioritized treatment to elastic data, BCP for DiffServ in nested VPNs and others. Thanks, Pratik -----Original Message----- From: ieprep-bounces@ietf.org [mailto:ieprep-bounces@ietf.org] On Behalf Of King, Kimberly S. Sent: Thursday, June 30, 2005 10:24 AM To: Ieprep (ieprep@ietf.org) Cc: sob@harvard.edu; Jon Peterson (jon.peterson@neustar.biz) Subject: [Ieprep] Re-charter? 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 From ieprep-bounces@ietf.org Tue Jul 5 10:37:33 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28259 for ; Tue, 5 Jul 2005 10:18:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpoXC-0002zQ-GN for ieprep-archive@ietf.org; Tue, 05 Jul 2005 10:36:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpo5W-0002Zp-51; Tue, 05 Jul 2005 10:07:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpo4r-0001cE-HY; Tue, 05 Jul 2005 10:07:09 -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 KAA24758; Tue, 5 Jul 2005 10:00:55 -0400 (EDT) Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpoIM-0001LH-TX; Tue, 05 Jul 2005 10:21:07 -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 j65DrH7U001361; Tue, 5 Jul 2005 09:53:18 -0400 (EDT) Subject: Re: [Ieprep] Re-charter? To: "Jason Michael Canon" X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Dennis Q Berg Date: Tue, 5 Jul 2005 09:53:17 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 07/05/2005 09:53:04 AM MIME-Version: 1.0 X-Spam-Score: 0.8 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Cc: Jason Michael Canon , ieprep-bounces@ietf.org, Janet P Gunn , jon.peterson@neustar.biz, "King, Kimberly S." , 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1855980281==" Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb --===============1855980281== Content-type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 DQoNCg0KDQpbcmVzZW5kaW5nIGluIHBsYWluIHRleHQgYSBzY290dCdzIHJlcXVlc3RdDQpUbyBo ZWxwIHdpdGggeW91ciBxdWVzdGlvbjoNCg0KR0VUUyBhbmQgV1BTIHVzZSBwcmlvcml0eSBmZWF0 dXJlLCBub3QgcHJlZW1wdGlvbi4NCg0KVGhlIEZDQyBydWxlZCBvbiB0aGUgbGVnYWxpdHkgb2Yg Ym90aCBHRVRTIGFuZCBXUFMuICBTcGVjaWZpY2FsbHkgc2VlLCBGQ0MNClJlcG9ydCBhbmQgT3Jk ZXIsIEVzdGFibGlzaG1lbnQgb2YgUnVsZXMgYW5kIFJlZ3VsYXRpb25zIGZvciBQcmlvcml0eQ0K QWNjZXNzLCBTZWNvbmQgUmVwb3J0IGFuZCBPcmRlciAjOTYtODYsIDMgSnVseSAyMDAwLg0KDQpJ biBjb21wbGlhbmNlIHdpdGggdGhlIEZDQyBSJk8sIGZ1bmN0aW9uYWxpdHkgd2FzIGRlc2lnbmVk IGFuZCBkZXZlbG9wZWQgaW4NCldpcmVsZXNzIFByaW9yaXR5IFNlcnZpY2UgdG8gYXNzdXJlIHRo YXQgdGhlIHB1YmxpYyBpcyBnaXZlbiBhZGVxdWF0ZQ0KYWNjZXNzLiAgVGhpcyBmZWF0dXJlLCBS ZXNvdXJjZSBDYXBhY2l0eSBBc3N1cmFuY2UgZm9yIHRoZSBQdWJsaWMgKFJDQVApDQpnb3Zlcm5z IGFsbG9jYXRpb24gb2Ygd2lyZWxlc3MgcmFkaW8gcmVzb3VyY2VzIGJldHdlZW4gcHVibGljIGFu ZCBXUFMNCmNhbGxzLiAgVGhlIGN1cnJlbnQgZGVmYXVsdCByZXNlcnZlcyBzZXZlcmFsIHRpbWVz IG1vcmUgY2FwYWNpdHkgZm9yIHRoZQ0KcHVibGljIHRoYW4gZm9yIHVzZXJzIG9mIHRoZSBwcmlv cml0eSBzZXJ2aWNlLiAgRXh0ZW5zaXZlIG1vZGVsaW5nIGFuZA0KYW5hbHlzaXMgaGF2ZSBiZWVu IHBlcmZvcm1lZCB0byBwcmVkaWN0IHRoZSBhZGVxdWFjeSBvZiB0aGUgZmVhdHVyZS4gIFRoZQ0K cmVzdWx0cyBzaG93IGluc2lnbmlmaWNhbnQgaW1wYWN0IG9mIFdQUyB0cmFmZmljIG9uIHRoZSBw dWJsaWMgaW4gYQ0Kc3BlY3RydW0gb2YgcGxhdXNpYmxlIGNvbmdlc3Rpb24gc2NlbmFyaW9zLg0K DQpIb3BlIHRoYXQgaGVscHMuDQoNCkRlbm5pcw0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCg0KVGhpcyBpcyBhIFBSSVZBVEUgbWVzc2FnZS4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlDQpkZWxldGUgd2l0aG91dCBjb3B5aW5nIGFuZCBr aW5kbHkgYWR2aXNlIHVzIGJ5IGUtbWFpbCBvZiB0aGUgbWlzdGFrZSBpbg0KZGVsaXZlcnkuIE5P VEU6IFJlZ2FyZGxlc3Mgb2YgY29udGVudCwgdGhpcyBlLW1haWwgc2hhbGwgbm90IG9wZXJhdGUg dG8NCmJpbmQgQ1NDIHRvIGFueSBvcmRlciBvciBvdGhlciBjb250cmFjdCB1bmxlc3MgcHVyc3Vh bnQgdG8gZXhwbGljaXQgd3JpdHRlbg0KYWdyZWVtZW50IG9yIGdvdmVybm1lbnQgaW5pdGlhdGl2 ZSBleHByZXNzbHkgcGVybWl0dGluZyB0aGUgdXNlIG9mIGUtbWFpbA0KZm9yIHN1Y2ggcHVycG9z ZS4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoNCg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgIkphc29uIE1pY2hhZWwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICBD YW5vbiIgPGZpYXRsdXggICAgICAgICAgVG86ICAgICAgIkphc29uIE1pY2hhZWwgQ2Fub24iIDxm aWF0bHV4QGFkZWxwaGlhLm5ldD4sICJLaW5nLCBLaW1iZXJseSBTLiIgICAgICAgICAgICAgIA0K ICAgICAgICAgICAgICAgICAgICAgIEBhZGVscGhpYS5uZXQ+ICAgICAgICAgICA8S0lNQkVSTFku Uy5LSU5HQHNhaWMuY29tPiwgSmFuZXQgUCBHdW5uL0ZFRC9DU0NAQ1NDICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgU2VudCBieTogICAg ICAgICAgICAgICAgIGNjOiAgICAgIGllcHJlcC1ib3VuY2VzQGlldGYub3JnLCBqb24ucGV0ZXJz b25AbmV1c3Rhci5iaXosIGllcHJlcEBpZXRmLm9yZywgICAgICAgICAgICANCiAgICAgICAgICAg ICAgICAgICAgICBpZXByZXAtYm91bmNlcyAgICAgICAgICAgc29iQGhhcnZhcmQuZWR1ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBTdWJqZWN0OiBSZTogW0llcHJlcF0gUmUtY2hhcnRlcj8gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN CiAgICAgICAgICAgICAgICAgICAgICAwNy8wMS8yMDA1IDA0OjU4ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgIFBNICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNCg0KDQpTb3JyeSwgSSBtZWFu dCBHRVRTL1dQUyBhbmQgTUxQUC4NCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJv bTogIkphc29uIE1pY2hhZWwgQ2Fub24iIDxmaWF0bHV4QGFkZWxwaGlhLm5ldD4NClRvOiAiS2lu ZywgS2ltYmVybHkgUy4iIDxLSU1CRVJMWS5TLktJTkdAc2FpYy5jb20+OyAiSmFuZXQgUCBHdW5u Ig0KPGpndW5uNkBjc2MuY29tPg0KQ2M6IDxpZXByZXAtYm91bmNlc0BpZXRmLm9yZz47IDxpZXBy ZXBAaWV0Zi5vcmc+Ow0KPGpvbi5wZXRlcnNvbkBuZXVzdGFyLmJpej47IDxzb2JAaGFydmFyZC5l ZHU+DQpTZW50OiBGcmlkYXksIEp1bHkgMDEsIDIwMDUgNDo1NCBQTQ0KU3ViamVjdDogUmU6IFtJ ZXByZXBdIFJlLWNoYXJ0ZXI/DQoNCg0KSSBoYXZlIGEgZ2VuZXJpYywgaGlnaCBsZXZlbCBxdWVz dGlvbi4NCg0KQXMgYSBjaXZpbGlhbiBpbiBhbiBlbWVyZ2VuY3kgc2l0dWF0aW9uIEkgY2FsbCA5 LTEtMSB0byByZXBvcnQgc29tZSBsaWZlDQp0aHJlYXRlbmluZyBzaXR1YXRpb24gaW4gbXkNCmhv dXNlLiAgV2hpbGUgdGhlIGNhbGwgaXMgaW4gcHJvZ3Jlc3MgYSBzdWZmaWNpZW50IG51bWJlciBv ZiBnb3Zlcm5tZW50DQpvZmZpY2lhbHMgZXZva2UgYSBHRVRTL1dBUw0Kb3IgTU9QIGNhcGFiaWxp dHkgYW5kIG15IGNhbGwgaXMgZWZmZWN0aXZlbHkgcHJlZW1wdGVkIG9yIGRlZ3JhZGVkIHRvIGEN CmxldmVsIHRoYXQgaXMgbm90IHRvbGVyYWJsZS4NCk15IHF1ZXN0aW9uIGlzIGRpZCBhIHB1Ymxp YyBwb2xpY3kgZGViYXRlIHJlc3VsdCBpbiBhIENvbmdyZXNzaW9uYWwgbGF3IG9yDQpGQ0MgUmVn dWxhdGlvbiB0aGF0IHBlcm1pdHMNCnRoZSBJVEVNIHRvIGNyYWZ0IGVuYWJsaW5nIHRlY2hub2xv Z3k/ICBJZiBzbywgYSByZWZlcmVuY2UgdG8gdGhlIGRvY3VtZW50DQp3b3VsZCBiZSBncmVhdGx5 DQphcHByZWNpYXRlZC4NCg0KVGhhbmtzLA0KSmFzb24NCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2Fn ZSAtLS0tLQ0KRnJvbTogIkphbmV0IFAgR3VubiIgPGpndW5uNkBjc2MuY29tPg0KVG86ICJLaW5n LCBLaW1iZXJseSBTLiIgPEtJTUJFUkxZLlMuS0lOR0BzYWljLmNvbT4NCkNjOiA8aWVwcmVwLWJv dW5jZXNAaWV0Zi5vcmc+OyA8am9uLnBldGVyc29uQG5ldXN0YXIuYml6PjsNCjxpZXByZXBAaWV0 Zi5vcmc+OyA8c29iQGhhcnZhcmQuZWR1Pg0KU2VudDogRnJpZGF5LCBKdWx5IDAxLCAyMDA1IDQ6 MDEgUE0NClN1YmplY3Q6IFJlOiBbSWVwcmVwXSBSZS1jaGFydGVyPw0KDQoNCj4NCj4NCj4NCj4N Cj4gSSBoYXZlIGEgZ2VuZXJpYywgaGlnaCBsZXZlbCBjb21tZW50Lg0KPg0KPiBJZiB3ZSBhcmUg ZXh0ZW5kaW5nIHRoZSBjaGFydGVyIGZyb20g4oCccmVxdWlyZW1lbnRzIG9ubHnigJ0gdG8g4oCc cmVxdWlyZW1lbnRzDQo+IGFuZCBzb2x1dGlvbnMgd2hlcmUgbm90IGNvdmVyZWQgZWxzZXdoZXJl 4oCdLCAgSSB0aGluayB0aGUgc29sdXRpb24gc3BhY2UNCj4gc2hvdWxkIGluY2x1ZGUgc29sdXRp b25zIGZvciDigJx0aGUgZXZvbHV0aW9uIG9mIEdFVFMvV1BTIHRvIElQ4oCdIGFzIHdlbGwgYXMN Cj4gc29sdXRpb25zIGZvciDigJx0aGUgZXZvbHV0aW9uIG9mIE1MUFAgdG8gSVDigJ0uDQo+DQo+ IFNpbWlsYXJseSwgdGhlIHJlcXVpcmVtZW50cyBhbmQgZnJhbWV3b3JrcyB0aGF0IGhhdmUgYmVl biBwcmV2aW91c2x5DQo+IHByb2R1Y2VkIGNvdmVyIHRoZSBlbnRpcmUgSUVQUkVQIHNjb3BlLCBi b3RoICJzb3J0IG9mIGxpa2UgTUxQUCIgYW5kDQoic29ydA0KPiBvZiBsaWtlIEdFVFMiLiAgU28g SSB0aGluayBpdCB3b3VsZCBiZSBhcHByb3ByaWF0ZSB0byBoYXZlIGRlbGl2ZXJhYmxlcw0KPiBz dWNoIGFzDQo+ICJFbWVyZ2VuY3kgVGhyZWF0cyBBbmFseXNpcyBmb3IgQ29tbWVyY2lhbC9QdWJs aWMgTmV0d29ya3MiDQo+ICJSZXF1aXJlbWVudHMgZm9yIEVtZXJnZW5jeSBQcmVwYXJlZG5lc3Mg aW4gQ29tbWVyY2lhbC9QdWJsaWMgTmV0d29ya3MiDQo+ICJQb3RlbnRpYWwgU29sdXRpb25zIGZv ciBDb21tZXJjaWFsL1B1YmxpYyBOZXR3b3JrcyINCj4gIk1lY2hhbmlzbXMgdG8gYmUgVXNlZCBi eSBDb21tZXJjaWFsL1B1YmxpYyBOZXR3b3JrcyINCj4gYXMgd2VsbCBhcyB0aGUgb25lcyBwcm9w b3NlZCBmb3IgIkdvdmVybm1lbnQvTWlsaXRhcnkgTmV0d29ya3MiLg0KPg0KPiBJIHRoaW5rIHRo YXQgd291bGQgYmUgbW9yZSB1c2VmdWwgdGhhbiAiRGlmZmVyZW5jZXMgYmV0d2VlbiBHRVRTIGFu ZCBNTFBQDQo+IG5ldHdvcmtzIiwgZXNwZWNpYWxseSBzaW5jZSBzb21lIG9mIHRoZSBkaWZmZXJl bmNlcyB3aGljaCBhcmUgc2lnbmlmaWNhbnQNCj4gaW4gdGhlIGNpcmN1aXQgc3dpdGNoZWQgd29y bGQgbWF5IGJlIGxlc3Mgc2lnbmlmaWNhbnQgaW4gdGhlIHBhY2tldA0KPiBzd2l0Y2hlZCB3b3Js ZC4gIEJ1dCBtYXliZSBpZiBJIHNhdyBhbiBhYnN0cmFjdCBvZiB3aGF0IHdhcyBpbnRlbmRlZCBm b3INCj4gdGhlIGRvY3VtZW50LCBJIHdvdWxkIGNoYW5nZSBteSBtaW5kLg0KPg0KPiBKYW5ldA0K Pg0KPg0KPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo+DQo+IFRoaXMgaXMg YSBQUklWQVRFIG1lc3NhZ2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQs IHBsZWFzZQ0KPiBkZWxldGUgd2l0aG91dCBjb3B5aW5nIGFuZCBraW5kbHkgYWR2aXNlIHVzIGJ5 IGUtbWFpbCBvZiB0aGUgbWlzdGFrZSBpbg0KPiBkZWxpdmVyeS4gTk9URTogUmVnYXJkbGVzcyBv ZiBjb250ZW50LCB0aGlzIGUtbWFpbCBzaGFsbCBub3Qgb3BlcmF0ZSB0bw0KPiBiaW5kIENTQyB0 byBhbnkgb3JkZXIgb3Igb3RoZXIgY29udHJhY3QgdW5sZXNzIHB1cnN1YW50IHRvIGV4cGxpY2l0 DQo+IHdyaXR0ZW4NCj4gYWdyZWVtZW50IG9yIGdvdmVybm1lbnQgaW5pdGlhdGl2ZSBleHByZXNz bHkgcGVybWl0dGluZyB0aGUgdXNlIG9mIGUtbWFpbA0KPiBmb3Igc3VjaCBwdXJwb3NlLg0KPg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo+DQo+DQo+DQo+DQo+DQo+ICAgICAg ICAgICAgICAgICAgICAgICJLaW5nLCBLaW1iZXJseQ0KPiAgICAgICAgICAgICAgICAgICAgICBT LiIgICAgICAgICAgICAgICAgICAgICAgVG86ICAgICAgIkllcHJlcA0KPiAoaWVwcmVwQGlldGYu b3JnKSIgPGllcHJlcEBpZXRmLm9yZz4NCj4gICAgICAgICAgICAgICAgICAgICAgPEtJTUJFUkxZ LlMuS0lORyAgICAgICAgIGNjOiAgICAgIHNvYkBoYXJ2YXJkLmVkdSwNCj4gIkpvbiBQZXRlcnNv biBcKGpvbi5wZXRlcnNvbkBuZXVzdGFyLmJpelwpIg0KPiAgICAgICAgICAgICAgICAgICAgICBA c2FpYy5jb20+ICAgICAgICAgICAgICAgPGpvbi5wZXRlcnNvbkBuZXVzdGFyLmJpej4NCj4gICAg ICAgICAgICAgICAgICAgICAgU2VudCBieTogICAgICAgICAgICAgICAgIFN1YmplY3Q6IFtJZXBy ZXBdDQo+IFJlLWNoYXJ0ZXI/DQo+ICAgICAgICAgICAgICAgICAgICAgIGllcHJlcC1ib3VuY2Vz DQo+DQo+DQo+ICAgICAgICAgICAgICAgICAgICAgIDA2LzMwLzIwMDUgMTA6MjQNCj4gICAgICAg ICAgICAgICAgICAgICAgQU0NCj4NCj4NCj4NCj4NCj4NCj4NCj4gU2NvdHQgYW5kIEkgaGF2ZSBh c2tlZCBmb3IgYSAxIGhvdXIgbWVldGluZyBzbG90IGF0DQo+IHRoZSBQYXJpcyBJRVRGIG1lZXRp bmcgdG8gZGlzY3VzcyBhIHBvc3NpYmxlIHJlLWNoYXJ0ZXINCj4gb2YgaWVwcmVwLiAgQSBwcm92 aXNpb25hbCBuZXcgY2hhcnRlciBpcyBpbmNsdWRlZCBiZWxvdy4NCj4NCj4gS2ltYmVybHkNCj4N Cj4NCj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4gRHJhZnQg cmV2aXNpb24NCj4gSW50ZXJuZXQgRW1lcmdlbmN5IFByZXBhcmVkbmVzcyAoaWVwcmVwKSBDaGFy dGVyDQo+DQo+IERlc2NyaXB0aW9uIG9mIFdvcmtpbmcgR3JvdXA6DQo+DQo+IEVmZmVjdGl2ZSB0 ZWxlY29tbXVuaWNhdGlvbnMgY2FwYWJpbGl0aWVzIGFyZSBpbXBlcmF0aXZlIHRvDQo+IGZhY2ls aXRhdGUgaW1tZWRpYXRlIHJlY292ZXJ5IG9wZXJhdGlvbnMgZm9yIHNlcmlvdXMNCj4gZGlzYXN0 ZXIgZXZlbnRzIGluY2x1ZGluZyBuYXR1cmFsIGRpc2FzdGVycyAoZS5nLiwNCj4gaHVycmljYW5l cywgZmxvb2RzLCBlYXJ0aHF1YWtlcykgYW5kIHRob3NlIGNyZWF0ZWQgYnkgbWFuDQo+IChlLmcu LCB0ZXJyb3Jpc3QgYXR0YWNrcywgY29tYmF0IHNpdHVhdGlvbnMgb3Igd2FydGltZQ0KPiBldmVu dHMpLiAgSW4gYWRkaXRpb24sIHJlbGF0ZWQgY2FwYWJpbGl0aWVzIHNob3VsZCBiZSB1c2FibGUN Cj4gaW4gbm9ybWFsIGNvbW1hbmQgYW5kIGNvbnRyb2wgb3BlcmF0aW9ucyBvZiBtaWxpdGFyeQ0K PiBzZXJ2aWNlcywgd2hpY2ggb2Z0ZW4gaGF2ZSB0aW1lbGluZXNzIHJlcXVpcmVtZW50cyBldmVu IGluDQo+IHBlYWNldGltZS4gIFRoZSBJRVBSRVAgV0cgd2lsbCBhZGRyZXNzIHByb2FjdGl2ZSBh bmQNCj4gcmVhY3RpdmUgcm9idXN0bmVzcyBhbmQgcmVjb3ZlcnkgZnJvbSB2YXJpb3VzIG91dGFn ZXMgdXNpbmcNCj4gdGhyZWUgcGVyc3BlY3RpdmVzOg0KPg0KPiAxLiBBIGNvbW1lcmNpYWwgKGku ZS4sIG9yIHB1YmxpYykgdGVsZWNvbW11bmljYXRpb25zDQo+IGluZnJhc3RydWN0dXJlDQo+DQo+ IDIuIEEgZ292ZXJubWVudGFsL21pbGl0YXJ5IHRlbGVjb21tdW5pY2F0aW9ucyBpbmZyYXN0cnVj dHVyZQ0KPiB0aGF0IG1heSByZXRhaW5zIHNvbGUgb3duZXJzaGlwIGFuZCBhZG1pbmlzdHJhdGlv biBvZiBpdHMNCj4gb3duIHJlc291cmNlcw0KPg0KPiAzLiBBIGdvdmVybm1lbnRhbC9taWxpdGFy eSB0ZWxlY29tbXVuaWNhdGlvbnMgaW5mcmFzdHJ1Y3R1cmUNCj4gdGhhdCBjb21iaW5lcyBwcml2 YXRlIHJlc291cmNlcyBhbmQgbGV2ZXJhZ2VzIHB1YmxpYw0KPiBpbmZyYXN0cnVjdHVyZS4gIFRo aXMgc2NlbmFyaW8gbWF5IGJlIHN1YmplY3QgdG8gbG9jYWwNCj4gcG9saWNpZXMsIGxhd3MsIGFu ZCByZWd1bGF0aW9ucy4NCj4NCj4gRGlzYXN0ZXJzIGNhbiBoYXBwZW4gYW55IHRpbWUsIGFueSBw bGFjZSwgdW5leHBlY3RlZGx5Lg0KPiBRdWljayByZXNwb25zZSBmb3IgcmVjb3Zlcnkgb3BlcmF0 aW9ucyByZXF1aXJlcyBpbW1lZGlhdGUNCj4gYWNjZXNzIHRvIGFueSBwdWJsaWMgdGVsZWNvbW11 bmljYXRpb25zIGNhcGFiaWxpdGllcyBhdA0KPiBoYW5kLiBUaGVzZSBjYXBhYmlsaXRpZXMgaW5j bHVkZTogY29udmVudGlvbmFsIHRlbGVwaG9uZSwNCj4gY2VsbHVsYXIgcGhvbmVzLCBhbmQgSW50 ZXJuZXQgYWNjZXNzIHZpYSBvbmxpbmUgdGVybWluYWxzLA0KPiBJUCB0ZWxlcGhvbmVzLCBhbmQg d2lyZWxlc3MgUERBcy4gVGhlIGNvbW1lcmNpYWwNCj4gdGVsZWNvbW11bmljYXRpb25zIGluZnJh c3RydWN0dXJlIGlzIHJhcGlkbHkgZXZvbHZpbmcgdG8NCj4gSW50ZXJuZXQtYmFzZWQgdGVjaG5v bG9neS4gIFRoZXJlZm9yZSwgdGhlIEludGVybmV0DQo+IGNvbW11bml0eSBuZWVkcyB0byBjb25z aWRlciBob3cgaXQgY2FuIGJlc3Qgc3VwcG9ydA0KPiBlbWVyZ2VuY3kgbWFuYWdlbWVudCBhbmQg cmVjb3Zlcnkgb3BlcmF0aW9ucy4NCj4NCj4gUG90ZW50aWFsIGRpc2FzdGVycyBmb3IgZ292ZXJu bWVudGFsL21pbGl0YXJ5DQo+IGluZnJhc3RydWN0dXJlcyBjYW4gZXh0ZW5kIGJleW9uZCB3aGF0 IG1pZ2h0IGJlIGV4cGVyaWVuY2VkDQo+IGJ5IHRoZSBjb21tZXJjaWFsL3B1YmxpYyBzZWN0b3Ig YW5kIGNhbiBiZSBhbnRpY2lwYXRlZCB0bw0KPiBzb21lIGRlZ3JlZS4gIFRodXMsIHByb2FjdGl2 ZSBtZWNoYW5pc21zIHRvIGFkZHJlc3Mgd291bGQtYmUNCj4gb3V0YWdlcyBhcmUgcmVxdWlyZWQg Zm9yIHRoZXNlIHNjZW5hcmlvcy4NCj4NCj4gVGhlIElFUFJFUCBXRyB3aWxsIHdvcmsgb24gdGhl c2UgdGhyZWUgcGVyc3BlY3RpdmVzDQo+IChjb21tZXJjaWFsLCBnb3Zlcm5tZW50YWwvbWlsaXRh cnksIGFuZCB0aGUgY29tYmluYXRpb24pIGFuZA0KPiBzeW5lcmdpemUgY29tbW9uIG1lY2hhbmlz bXMgYW5kIHJlcXVpcmVtZW50cyBpbnRvIG90aGVyDQo+IGdyb3VwcyB3aGVyZSBwb3NzaWJsZSwg d2hpbGUgbWFpbnRhaW5pbmcgYSBzZXBhcmF0ZSB0cmFjayBvZg0KPiBJRVBSRVAgZG9jdW1lbnRz IGZvciB0aGUgdW5pcXVlIG1lY2hhbmlzbXMgYW5kIHJlcXVpcmVtZW50cw0KPiBvZiBlYWNoIHBl cnNwZWN0aXZlcy4NCj4NCj4gTm93IHRoYXQgdGhlIGluaXRpYWwgZG9jdW1lbnRzIGRlc2NyaWJl IHRoZSBicm9hZCBwcm9ibGVtDQo+IHNwYWNlIGFuZCBpdHMgc2FsaWVudCBjaGFyYWN0ZXJpc3Rp Y3MsIG5ldyBlZmZvcnRzIHdpbGwNCj4gZm9jdXMgb24gc3BlY2lmaWMgcmVxdWlyZW1lbnRzIGFu ZCBzb2x1dGlvbnMgc3VjaCBhcyB0aG9zZQ0KPiBwZXJ0YWluaW5nIHRvIHRoZSBnb3Zlcm5tZW50 YWwvbWlsaXRhcnkgc2VjdG9yLiAgT25lDQo+IGRvY3VtZW50IGV4aXN0cyBpbiB0aGUgVHJhbnNw b3J0IEFyZWEgd29ya2luZyBncm91cCBvZg0KPiBpbnRlcmVzdCB0byBJRVBSRVAgdGhhdCBjb3Vs ZCBzYXRpc2Z5IGEgZ292ZXJubWVudGFsDQo+IGZyYW1ld29yay9CQ1AgaXMgZHJhZnQtaWV0Zi10 c3Z3Zy1tbHBwLXRoYXQtd29ya3MtWFguICBUaGlzDQo+IGRvY3VtZW50IHdpbGwgcHJvZ3Jlc3Mg dG8gY29tcGxldGlvbiBpbiB0aGF0IFdHLCB5ZXQgYmUgdGhlDQo+IGJhc2lzIG9mIG1vcmUgd29y ayBpbiB0aGlzIElFUFJFUCBXRy4gIFNvbWUgYWRkaXRpb25hbA0KPiBlZmZvcnRzIG9uIHRoZSBn b3Zlcm5tZW50YWwvbWlsaXRhcnkgdHJhY2sgd2l0aGluIElFUFJFUA0KPiB3aWxsIGZvY3VzIG9u IHRoaXMgVFNWV0cgZG9jdW1lbnQsIGFuYWx5emUgZ2FwcywgYW5kIHByb3ZpZGUNCj4gaW5wdXQg d2hlcmUgbmVlZGVkLg0KPg0KPiBUaGUgZm9sbG93aW5nIGFyZSBmb3VyIHNwZWNpZmljIGV4YW1w bGVzIHRoYXQgY2FuIHNhdGlzZnkNCj4gdGhlIGludGVyZXN0cyBvZiBnb3Zlcm5tZW50YWwvbWls aXRhcnkgKGFuZCBwb3RlbnRpYWxseSwNCj4gY29tbWVyY2lhbC9wdWJsaWMpIGVtZXJnZW5jeSBj b21tdW5pY2F0aW9uczoNCj4NCj4gMS4gQ29udmV5aW5nIGluZm9ybWF0aW9uIGFib3V0IHRoZSBw cmlvcml0eSBvZiBzcGVjaWZpYw0KPiBmbG93cyAob3Igc2Vzc2lvbnMpIHRoYXQgb3JpZ2luYXRl IGluIGEgVm9JUCBlbnZpcm9ubWVudC4NCj4gVGhpcyBjb3VsZCBpbmNsdWRlIGEgcmVxdWlyZW1l bnRzIGVmZm9ydCB0byBkZXNjcmliZQ0KPiBleHRlbnNpb25zIHRvIE5TSVMgb3IgUlNWUC4gUmVx dWlyZW1lbnRzIGZvciBOU0lTIHdvdWxkIGJlDQo+IGZvcndhcmRlZCB0byB0aGUgTlNJUyB3b3Jr aW5nIGdyb3VwLiBSZXF1aXJlbWVudHMgZm9yIFJTVlANCj4gY291bGQgYmUgZm9yd2FyZGVkIHRv IHRzdndnIG9yIHdvcmtlZCBvbiBpbiBJRVBSRVAuDQo+DQo+IDIuIE5lc3RlZCBWUE5zIHJlcXVp cmUgc3BlY2lhbCBjb25zaWRlcmF0aW9ucyBmb3Igcm91dGluZw0KPiBhbmQgUW9TIGlmIG5vZGVz IGluIHRoZSBwYXRoIHRoYXQgbWFrZSB0aGVzZSBkZWNpc2lvbnMNCj4gZ2VuZXJhbGx5IGhhdmUg bGltaXRlZCBpbmZvcm1hdGlvbi4NCj4NCj4gMy4gU29tZSBjb3VudHJpZXMgcmVxdWlyZSBjaXZp bCBuZXR3b3JrcyB0byBwcmVlbXB0IHNlc3Npb25zDQo+IHVuZGVyIHN0YXRlIGNpcmN1bXN0YW5j ZXMsIGFuZCBwcmVlbXB0aW9uIGlzIGNvbnNpZGVyZWQgYW4NCj4gYWJzb2x1dGUgcmVxdWlyZW1l bnQgaW4gZ292ZXJubWVudGFsIG5ldHdvcmtzIGluIG1vc3QNCj4gY291bnRyaWVzLiBVbmxlc3Mg aW1wbGVtZW50YXRpb24gb2YgdGhlc2UgcmVxdWlyZW1lbnRzIGNhbg0KPiBiZSBvYmplY3RpdmVs eSBzaG93biB0byB0aHJlYXRlbiBuZXR3b3JrIGhlYWx0aCAodmlhDQo+IHNpbXVsYXRpb24gb3Ig aW4gb3BlcmF0aW9ucyksIHRoZW4gdGhlIHJlcXVpcmVtZW50IG5lZWRzIHRvDQo+IGJlIGNvbnNp ZGVyZWQgYnkgSUVQUkVQIGFuZCBzcGVjaWZpYyBzb2x1dGlvbnMgbXVzdCBiZQ0KPiBkZXZlbG9w ZWQuDQo+DQo+IDQuIE5vbi1yZWFsLXRpbWUgYXBwbGljYXRpb25zIHJlcXVpcmUgbWVhc3VyZXMg b2YgUW9TIGFuZA0KPiBvdGhlciBwcmVmZXJlbnRpYWwgdHJlYXRtZW50cywgYXMgdm9pY2Ugd2ls bCBub3QgYmUgdGhlIG9ubHkNCj4gYXBwbGljYXRpb24gdXNlZCBieSBJRVBSRVAuDQo+DQo+IElu IHRoZSBJRVRGLCBjb25zaWRlcmF0aW9ucyBmb3IgdHJlYXRtZW50IGFuZCBzZWN1cml0eSBvZg0K PiBlbWVyZ2VuY3kgY29tbXVuaWNhdGlvbnMgc3RyZXRjaCBhY3Jvc3MgYSBudW1iZXIgb2YgQXJl YXMNCj4gYW5kIFdvcmtpbmcgR3JvdXBzLCBub3RhYmx5IGluY2x1ZGluZyB0aGUgdmFyaW91cyB0 ZWxlcGhvbnkNCj4gc2lnbmFsaW5nIHdvcmtpbmcgZ3JvdXBzLCBQcm90b2NvbCBmb3IgY2Fycnlp bmcNCj4gQXV0aGVudGljYXRpb24gZm9yIE5ldHdvcmsgQWNjZXNzIChwYW5hKSwgdGhlIG9wZW4g VHJhbnNwb3J0DQo+IEFyZWEgZm9yIHBhdGgtY291cGxlZCBzaWduYWxpbmcgYW5kIHZhcmlvdXMg b3BlcmF0aW9uYWwNCj4gZ3JvdXBzLiBJRVBSRVAgd2lsbCBjb29wZXJhdGUgY2xvc2VseSB3aXRo IHRoZXNlIGdyb3VwcyBhbmQNCj4gd2l0aCB0aG9zZSBvdXRzaWRlIG9mIHRoZSBJRVRGIHN1Y2gg YXMgdmFyaW91cyBJVFUtVCBzdHVkeQ0KPiBncm91cHMuDQo+DQo+DQo+IElmIHRoZXJlIGlzIGFu IGV4aXN0aW5nIFdHIHRoYXQgY2FuIGRpc2N1c3MgdGhlIHJlcXVpcmVtZW50cw0KPiBmb3IgZXh0 ZW5kaW5nIHRoZWlyIHByb3RvY29sIG9yIG1lY2hhbmlzbSwgSUVQUkVQIHdpbGwNCj4gZ2VuZXJh dGUgb25seSBhIHJlcXVpcmVtZW50cyBkb2N1bWVudCBmb3IgdGhhdCBncm91cCB0bw0KPiBkaXNj dXNzLg0KPg0KPiBJZiB0aGVyZSBpcyBub3QgYW4gZXhpc3RpbmcgV0cgdGhhdCBjYW4gZGlzY3Vz cyB0aGUNCj4gcmVxdWlyZW1lbnRzIGZvciBleHRlbmRpbmcgdGhlaXIgcHJvdG9jb2wgb3IgbWVj aGFuaXNtLA0KPiBJRVBSRVAgd2lsbCBwcmVwYXJlIHJlcXVpcmVtZW50cyBhbmQgZGlzY3VzcyB0 aGUgZXh0ZW5zaW9uDQo+IG9mIHRoYXQgcHJvdG9jb2wvbWVjaGFuaXNtIG9yIHByb3RvY29scy9t ZWNoYW5pc21zIHdpdGhpbg0KPiBJRVBSRVAuDQo+DQo+DQo+IEdvYWxzIGFuZCBNaWxlc3RvbmVz Og0KPg0KPiBEb25lICAgU3VibWl0IGluaXRpYWwgSS1EIG9mIFJlcXVpcmVtZW50cw0KPg0KPiBE b25lICAgU3VibWl0IGluaXRpYWwgSS1EIG9mIEZyYW1ld29yaw0KPg0KPiBEb25lICAgU3VibWl0 IGluaXRpYWwgSS1EIG9mIFJlY29tbWVuZGF0aW9ucyBCQ1ANCj4NCj4gRG9uZSAgIFN1Ym1pdCBS ZXF1aXJlbWVudHMgSS1EIHRvIElFU0cgZm9yIHB1YmxpY2F0aW9uIGFzIGFuDQo+ICAgICAgIElu Zm9ybWF0aW9uYWwgUkZDDQo+DQo+IERvbmUgICBTdWJtaXQgRnJhbWV3b3JrIEktRCB0byBJRVNH IGZvciBwdWJsaWNhdGlvbiBhcyBhbg0KPiBJbmZvcm1hdGlvbmFsIFJGQw0KPg0KPiBEZWMgMDMg U3VibWl0IFJlY29tbWVuZGF0aW9ucyBJLUQgdG8gSUVTRyBmb3IgcHVibGljYXRpb24gYXMNCj4g YSBCQ1ANCj4NCj4gT2N0IDA1IFN1Ym1pdCBhbiBpbml0aWFsIEktRCBvZiBFbWVyZ2VuY3kgVGhy ZWF0cyBBbmFseXNpcw0KPiBvZiBHb3Zlcm5tZW50L01pbGl0YXJ5IE5ldHdvcmtzDQo+DQo+IERl YyAwNSBTdWJtaXQgYW4gaW5pdGlhbCBJLUQgb2YgRGlmZmVyZW5jZXMgYmV0d2VlbiBHRVRTIGFu ZA0KPiBNTFBQIE5ldHdvcmtzDQo+DQo+IEZlYiAwNiBTdWJtaXQgYW4gaW5pdGlhbCBJLUQgb2Yg UmVxdWlyZW1lbnRzIG9mDQo+IEdvdmVybm1lbnQvTWlsaXRhcnkgTmV0d29ya3MNCj4NCj4gTWFy IDA2IFN1Ym1pdCBhbiBpbml0aWFsIEktRCBvZiBDb25zaWRlcmF0aW9ucyBmb3IgcG90ZW50aWFs DQo+IHNvbHV0aW9ucyBvZiBHb3Zlcm5tZW50L01pbGl0YXJ5IE5ldHdvcmtzDQo+DQo+IEFwciAw NiBTdWJtaXQgYW4gaW5pdGlhbCBJLUQgb2YgTWVjaGFuaXNtcyB0byBiZSB1c2VkIGJ5DQo+ICAg ICAgIEdvdmVybm1lbnQvTWlsaXRhcnkgTmV0d29ya3MNCj4NCj4gT2N0IDA1IFN1Ym1pdCBmaW5h bCBJLUQgb2YgRW1lcmdlbmN5IFRocmVhdHMgQW5hbHlzaXMgb2YNCj4gICAgICAgR292ZXJubWVu dC9NaWxpdGFyeSBOZXR3b3JrcyB0byBJRVNHIGFzIEluZm9ybWF0aW9uYWwNCj4gUkZDDQo+DQo+ IEZlYiAwNiBTdWJtaXQgZmluYWwgSS1EIG9mIFJlcXVpcmVtZW50cyBvZg0KPiBHb3Zlcm5tZW50 L01pbGl0YXJ5IE5ldHdvcmtzIHRvIElFU0cgYXMgSW5mb3JtYXRpb25hbCBSRkMNCj4NCj4gQXBy IDA2IFN1Ym1pdCBmaW5hbCBJLUQgb2YgTWVjaGFuaXNtcyB0byBiZSB1c2VkIGJ5DQo+ICAgICAg IEdvdmVybm1lbnQvTWlsaXRhcnkgTmV0d29ya3MgdG8gSUVTRyBhcyBCQ1AgUkZDDQo+DQo+IFRo ZSB3b3JraW5nIGdyb3VwIHdpbGwgZGlzY3VzcyByZS1jaGFydGVyaW5nIGlmIGFkZGl0aW9uYWwN Cj4gZWZmb3J0cyBhcmUgYWdyZWVkIHVwb24gYnkgdGhlIFdHIChmb3IgZXhhbXBsZSwgd29yayBp dGVtcw0KPiByZWxhdGVkIHRvIHByb3RvY29scyBvdXRzaWRlIGV4aXN0aW5nIFdHcykuDQo+DQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEllcHJl cCBtYWlsaW5nIGxpc3QNCj4gSWVwcmVwQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2llcHJlcA0KPg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQoNCg0KDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IEllcHJlcCBtYWlsaW5nIGxpc3QNCj4gSWVwcmVwQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2llcHJlcA0KPg0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZXByZXAgbWFpbGluZyBsaXN0DQpJ ZXByZXBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ll cHJlcA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpJZXByZXAgbWFpbGluZyBsaXN0DQpJZXByZXBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3MS5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2llcHJlcA0KDQo= --===============1855980281== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep --===============1855980281==-- From ieprep-bounces@ietf.org Tue Jul 5 18:44:30 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11047 for ; Tue, 5 Jul 2005 18:40:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpwII-0002KA-Re for ieprep-archive@ietf.org; Tue, 05 Jul 2005 18:53:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpvpr-0002as-Lb; Tue, 05 Jul 2005 18:24:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpvpo-0002Zp-Sm for ieprep@megatron.ietf.org; Tue, 05 Jul 2005 18:24:09 -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 SAA08820 for ; Tue, 5 Jul 2005 18:24:03 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dpw8W-00084B-5x for ieprep@ietf.org; Tue, 05 Jul 2005 18:43:28 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 05 Jul 2005 15:15:33 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j65MF46x028334; Tue, 5 Jul 2005 15:15:28 -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:15:25 -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:15:24 -0700 Message-Id: <4.3.2.7.2.20050705170848.03b43730@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 05 Jul 2005 17:15:22 -0500 To: Henning Schulzrinne , "King, Kimberly S." From: "James M. Polk" Subject: Re: [Ieprep] Re-charter? [Sessions?] In-Reply-To: <42C40623.7010303@cs.columbia.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 05 Jul 2005 22:15:24.0431 (UTC) FILETIME=[0A7029F0:01C581AF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: "Ieprep \(ieprep@ietf.org\)" , sob@harvard.edu, "Jon Peterson \(jon.peterson@neustar.biz\)" X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Henning At 10:48 AM 6/30/2005 -0400, Henning Schulzrinne wrote: >Brief remark: I'm not sure what "sessions" refers to in the snippet below. >Is this addressed to the application layer session (say, SIP), a network >layer session (RSVP, NSIS) or something else entirely? I believe this needs to be defined, but is loosely the combination of the two since a SIP session can be a call, and a reserved flow can be a call, and the combination can be a call. If you only use something like SIP, that a SIP session is the definition. IEPREP isn't likely going to only use RSVP or NSIS for flows, but either in combination with something like SIP. >In general, given the tortuous history of IEPREP discussions, more >specificity as to the types of mechanisms and protocols affected would be >helpful, in my opinion. "more specificity" would entail a deep analysis of the problem space - which the first 3 new deliverables will cover. You are asking for an ID to be written to justify the recharter? >Are there existing drafts that will be used as baseline (or input) draft-ietf-tsvwg-mlpp-that-works is mention is this new charter >or this is a from-scratch effort? > >King, Kimberly S. wrote: > >>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. > >_______________________________________________ >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 From ieprep-bounces@ietf.org Tue Jul 5 18:44:31 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11080 for ; Tue, 5 Jul 2005 18:41:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpwHd-0002Ho-Fr for ieprep-archive@ietf.org; Tue, 05 Jul 2005 18:52:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpvpN-0002Lu-HG; Tue, 05 Jul 2005 18:23:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpvpK-0002KW-O4; Tue, 05 Jul 2005 18:23: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 SAA08467; Tue, 5 Jul 2005 18:23:35 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpwFK-00011A-Ut; Tue, 05 Jul 2005 18:50:31 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 05 Jul 2005 15:22:36 -0700 X-IronPort-AV: i="3.93,263,1115017200"; d="scan'208"; a="196488862:sNHT31032256" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j65MMF71005066; Tue, 5 Jul 2005 15:22:33 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Jul 2005 15:22:29 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.120.51]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Jul 2005 15:22:28 -0700 Message-Id: <4.3.2.7.2.20050705171659.026c6a28@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 05 Jul 2005 17:22:27 -0500 To: Janet P Gunn , Henning Schulzrinne From: "James M. Polk" Subject: Re: [Ieprep] Re-charter? [solutions already?] In-Reply-To: References: <42C40623.7010303@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 05 Jul 2005 22:22:28.0770 (UTC) FILETIME=[075D2820:01C581B0] X-Spam-Score: 0.8 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: "King, Kimberly S." , ieprep-bounces@ietf.org, "Ieprep \(ieprep@ietf.org\)" , "Jon Peterson \(jon.peterson@neustar.biz\)" , sob@harvard.edu X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 At 03:31 PM 7/1/2005 -0400, Janet P Gunn wrote: >Closely related to the question "what is a session" is the question"what is >pre-emption?" In the circuit switched world, a connection is "nailed up" >and there is little confusion on what constitutes a "session" or >"pre-emption". If RSVP is used (or NSIS when it becomes a protocol), the coupling of SIP (for example) to the reservation protocol reduces this confusion, do you not agree? >But in the IP world, even if we restrict our discussion to SIP related >sessions, it is not so clear. For SIP, RFC3261 defines what a session is. IEPREP doesn't need to redefine it. >Once a session has been established, how many >packets need to be dropped, how bad does the "quality" need to get, before >we declare that the session has "failed" or been "pre-empted"? Perhaps this is part of the first two deliverables: 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 We should not be considering the definition of IP traffic in this WG. >Looking at it from another perspective, If traffic engineering indicates >that a given (IP) interface or route can accept 100 simultaneous calls with >a given QoS, but there is a mechanism to allow "special" calls to be >accepted (without actually tearing down existing calls) above that >threshold, at what point do I declare that the "special" calls are >pre-empting "regular calls"? the above is asking for a solution - which is premature at this point IMO >As soon as I exceed the engineered >capacity(typically a utilization less than 100%)? Once I exceed the raw >capacity (even though all calls may continue to meet the specified QoS)? >When a single call drops below its QoS specification? For how long? > >And so on. > >While the CONCEPT of "pre-emption based" vs. "non-pre-emption based" >carries over from the circuit switched world, and is useful in the IP world >(especially when IP networks are operating under rules and regulations >developed for the circuit switched world), the specific definition do not >carry over with any intrinsic clarity. > >If we are going to go down this path, I think the first step is to agree on >a consistent set of definitions. this will be part of an early doc IMO >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. >---------------------------------------------------------------------------------------- > > > > > > > Henning > > Schulzrinne S." > @cs.columbia.edu cc: "Jon Peterson > \(jon.peterson@neustar.biz\)" > > > , sob@harvard.edu, "Ieprep \(ieprep@ietf.org\)" > Sent > by: > > ieprep-bounces Subject: Re: [Ieprep] > Re-charter? > > > > > 06/30/2005 > 10:48 > > AM > > > > > > > >Brief remark: I'm not sure what "sessions" refers to in the snippet >below. Is this addressed to the application layer session (say, SIP), a >network layer session (RSVP, NSIS) or something else entirely? > >In general, given the tortuous history of IEPREP discussions, more >specificity as to the types of mechanisms and protocols affected would >be helpful, in my opinion. Are there existing drafts that will be used >as baseline (or input) or this is a from-scratch effort? > >King, Kimberly S. wrote: > > > 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. > > > >_______________________________________________ >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 From ieprep-bounces@ietf.org Tue Jul 5 18:56:56 2005 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 ; 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" , "Jason Michael Canon" , "King, Kimberly S." , "Janet P Gunn" From: "James M. Polk" Subject: RE: [Ieprep] Re-charter? [MLPP limited to private nets] In-Reply-To: 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 List-Unsubscribe: , List-Post: List-Help: List-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=20 networks, so if the capability becomes available in products, others will=20 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=20 >routine traffic. > >One (I think ) outstanding question is whether 911 on the public net gets= =20 >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" > > To: "King, Kimberly S." ; "Janet P Gunn" > > > > Cc: ; ; > > ; > > 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" > > To: "King, Kimberly S." > > Cc: ; ; > > ; > > 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 =E2=80=9Crequirements only=E2=80= =9D > > to =E2=80=9Crequirements > > > and solutions where not covered elsewhere=E2=80=9D, I think the > > solution space > > > should include solutions for =E2=80=9Cthe evolution of GETS/WPS > > to IP=E2=80=9D as well as > > > solutions for =E2=80=9Cthe evolution of MLPP to IP=E2=80=9D. > > > > > > 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)" > > > > sob@harvard.edu, > > > "Jon Peterson \(jon.peterson@neustar.biz\)" > > > @saic.com> > > > > > 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 From ieprep-bounces@ietf.org Tue Jul 5 19:02:19 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13064 for ; Tue, 5 Jul 2005 18:57:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpwXo-0005wk-PN for ieprep-archive@ietf.org; Tue, 05 Jul 2005 19:09:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpw62-00086I-Aw; Tue, 05 Jul 2005 18:40:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpw5z-00083T-77; Tue, 05 Jul 2005 18:40:53 -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 SAA10922; Tue, 5 Jul 2005 18:40:46 -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 1DpwKe-0002pW-EU; Tue, 05 Jul 2005 18:56:01 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 05 Jul 2005 15:28:04 -0700 X-IronPort-AV: i="3.93,263,1115017200"; d="scan'208"; a="290119634:sNHT38020882" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j65MRUW1022254; Tue, 5 Jul 2005 15:28:02 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Jul 2005 15:27:59 -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:27:58 -0700 Message-Id: <4.3.2.7.2.20050705172249.0266cfb8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 05 Jul 2005 17:27:56 -0500 To: "Jason Michael Canon" , "Jason Michael Canon" , "King, Kimberly S." , "Janet P Gunn" From: "James M. Polk" Subject: Re: [Ieprep] Re-charter? [IP911 and preemption] In-Reply-To: <012b01c57e7f$911ed330$6401a8c0@canondownstairs> References: <011401c57e7f$05227da0$6401a8c0@canondownstairs> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 05 Jul 2005 22:27:58.0525 (UTC) FILETIME=[CBE9C6D0:01C581B0] X-Spam-Score: 0.8 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ieprep-bounces@ietf.org, ieprep@ietf.org, jon.peterson@neustar.biz, sob@harvard.edu X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Jason At 04:58 PM 7/1/2005 -0400, Jason Michael Canon wrote: >Sorry, I meant GETS/WPS and MLPP. > >----- Original Message ----- From: "Jason Michael Canon" > >To: "King, Kimberly S." ; "Janet P Gunn" > >Cc: ; ; >; >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. IEPREP doesn't address 911 calling, ECRIT does - and currently has frowned upon the use of prioritizing sessions/flows/calls in its efforts to date. >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. As Dennis and others pointed out, currently, there is no preemption on the public circuit-switched networks for GETS. I believe the E911 example is the reason for the rule of "no preemption" by GETS. >Thanks, >Jason 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 From ieprep-bounces@ietf.org Tue Jul 5 19:24:35 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15516 for ; Tue, 5 Jul 2005 19:14:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dpx3K-0007Sx-Rr for ieprep-archive@ietf.org; Tue, 05 Jul 2005 19:42:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpwas-0001Yi-Va; Tue, 05 Jul 2005 19:12:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpwaq-0001WX-JX; Tue, 05 Jul 2005 19:12:45 -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 SAA08755; Tue, 5 Jul 2005 18:23:57 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpwA1-0008Co-VU; Tue, 05 Jul 2005 18:45:03 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 05 Jul 2005 15:17:07 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j65MH06t000255; Tue, 5 Jul 2005 15:17:04 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Jul 2005 15:16:49 -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:16:48 -0700 Message-Id: <4.3.2.7.2.20050705171538.03ae8e18@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 05 Jul 2005 17:16:47 -0500 To: Dennis Q Berg , "King, Kimberly S." From: "James M. Polk" Subject: Re: [Ieprep] Re-charter? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 05 Jul 2005 22:16:49.0103 (UTC) FILETIME=[3CE815F0:01C581AF] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ieprep-bounces@ietf.org, "Ieprep \(ieprep@ietf.org\)" , "Jon Peterson \(jon.peterson@neustar.biz\)" , sob@harvard.edu X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab At 11:17 AM 7/1/2005 -0400, Dennis Q Berg wrote: >Just a logistic note to start. For discussion of the charter, and if there >are also going to be any presentations, perhaps draft-ietf-tsvwg-mlpp-that-works because it is an existing ID >it strikes me that an hour is a bit >short. > >Dennis 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 From ieprep-bounces@ietf.org Tue Jul 5 23:01:04 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12329 for ; Tue, 5 Jul 2005 23:01:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dq0ak-0002CP-8i for ieprep-archive@ietf.org; Tue, 05 Jul 2005 23:28:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq088-0002ZR-P1; Tue, 05 Jul 2005 22:59:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq086-0002Wb-Nv; Tue, 05 Jul 2005 22:59:19 -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 WAA12040; Tue, 5 Jul 2005 22:59:16 -0400 (EDT) Received: from smtpauth04.mail.atl.earthlink.net ([209.86.89.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dq0Yy-0001ue-N2; Tue, 05 Jul 2005 23:27:06 -0400 Received: from pcp0010705485pcs.manass01.va.comcast.net ([69.243.36.229] helo=[127.0.0.1]) by smtpauth04.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1Dq07f-00025i-3B; Tue, 05 Jul 2005 22:58:51 -0400 Message-ID: <42CB4827.6000503@ix.netcom.com> Date: Tue, 05 Jul 2005 22:55:35 -0400 From: Janet Gunn Organization: None User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Ieprep] Re-charter? [MLPP limited to private nets] References: <012b01c57e7f$911ed330$6401a8c0@canondownstairs> <4.3.2.7.2.20050705172811.0262b6f0@email.cisco.com> In-Reply-To: <4.3.2.7.2.20050705172811.0262b6f0@email.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: ee238991c8bb1512372ac5f331c56529638061359fde3a277f028674192ef328bbe329f073e03f93350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.243.36.229 X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: Jason Michael Canon , ieprep-bounces@ietf.org, Janet P Gunn , jon.peterson@neustar.biz, "King, Kimberly S." , ieprep@ietf.org, sob@harvard.edu, Steve Silverman X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit James M. Polk wrote: > 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. > eMLPP IS in use in at least one non-military network (outside the US). Janet _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Thu Jul 7 08:35:37 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01108 for ; Thu, 7 Jul 2005 08:35:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqW2Z-0002oa-SM for ieprep-archive@ietf.org; Thu, 07 Jul 2005 09:03:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqVZI-0002ql-0o; Thu, 07 Jul 2005 08:33:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqVZH-0002pp-BK for ieprep@megatron.ietf.org; Thu, 07 Jul 2005 08:33: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 IAA00957 for ; Thu, 7 Jul 2005 08:33:25 -0400 (EDT) Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqW0P-00020Y-HL for ieprep@ietf.org; Thu, 07 Jul 2005 09:01:33 -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 j67CXLO7006865; Thu, 7 Jul 2005 08:33:21 -0400 (EDT) Subject: [Ieprep] Re-charter? To: "Ieprep (ieprep@ietf.org)" X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Dennis Q Berg Date: Thu, 7 Jul 2005 08:33:20 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 07/07/2005 08:33:02 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: sob@harvard.edu, "Jon Peterson \(jon.peterson@neustar.biz\)" X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Comments, reactions to the draft IEPREP charter inserted after text below. Dennis __________________ >The IEPREP WG will address proactive and >reactive robustness and recovery from various outages using >three perspectives: Why emphasize outages at the exclusion of congestions? >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. This taxonomy is going to cause confusion because it tries to summarize in three categories what it more than three, i.e. Public Private -------------------------------------------------------------- Commercial General Public, Enterprise Enterprise --------------------------------------------------------------- Gov't FTS, GETS various ----------------------------------------------------------------- Military DSN offnet DSN Perhaps it would be better to start with just the twofold distinction of the matrix: application (commercial, civilian Gov't, military) and network accessibility/control (public, private). >Thus, proactive mechanisms to address would-be >outages are required for these scenarios. Again, just outages and not "outages and congestion". >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. Seems that the end of this should be "...for the unique mechanisms and requirements for emergency preparedness of each perspective." >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. What documents are these? The completed IEPREP documents or the tsvwg-mlpp draft mentioned here? Why specifically single out one of the three perspectives rather than saying "new efforts will focus on specific requirements for solutions for each of the three perspectives"? >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. Should a charter reference a specific draft? Understand that this is supposed to be an example of the previous statement that other WGs will do the general mechanisms and requirements and IEPREP will do specifics that pertain to emergency preparedness - but it seems inappropriate to enshrine a specific example, especially when it is only a draft, and likely at least to need discussion if not being controversial in a WG charter. >The following are four specific examples that can satisfy >the interests of governmental/military (and potentially, >commercial/public) emergency communications: Just a clarity issue : this statement sounds like the four items following are solutions rather than what I think is meant: specific examples of issues that will be worked. >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 What ID is this. I don't see a document listed under IEPREP that fits this description. >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 The "GETS vs. MLPP" dichotomy does not seem to fit cleanly in to the framework of the three perspectives, since it is government/public using the same network as commercial/public (see comment above with matrix). To force it into the three perspectives framework, you would have to call it "government/commercial/public" - but that category doesn't exist in the three perspectives framework. Also, what would the scope of this document be in terms of the three general scopes referenced here - threats, requirements, solutions? >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 This list of documents seems to say that the recharter effort is not really going to work on the three perspectives, only one: the Gov't/Military. >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). Aren't these already included in the recharter under "mechanisms"? _______________________________________________ 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 From ieprep-bounces@ietf.org Thu Jul 7 09:43:01 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07317 for ; Thu, 7 Jul 2005 09:43:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqX5p-0000Am-8c for ieprep-archive@ietf.org; Thu, 07 Jul 2005 10:11:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqWdr-0006Q1-Kx; Thu, 07 Jul 2005 09:42:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqWdq-0006Pr-5Z for ieprep@megatron.ietf.org; Thu, 07 Jul 2005 09:42:14 -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 JAA07220 for ; Thu, 7 Jul 2005 09:42:11 -0400 (EDT) Message-Id: <200507071342.JAA07220@ietf.org> Received: from athena.hosts.co.uk ([212.84.175.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqX50-0008WU-91 for ieprep@ietf.org; Thu, 07 Jul 2005 10:10:20 -0400 Received: from [69.138.71.61] (helo=albers) by athena.hosts.co.uk with esmtpa (Exim 4.44) id 1DqWfs-0005O4-RC; Thu, 07 Jul 2005 14:44:24 +0100 From: "Ken Carlberg" To: "'Dennis Q Berg'" , "'Ieprep'" Subject: RE: [Ieprep] Re-charter? Date: Thu, 7 Jul 2005 09:41:09 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWC8PXy3O0cDZHsSP2Fxl82JQ3FigABK9lA X-Spam-Score: 2.0 (++) X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit > >The IEPREP WG will address proactive and > >reactive robustness and recovery from various outages using > >three perspectives: > > Why emphasize outages at the exclusion of congestions? the term outages was not meant to exclude the term congestion. this can be resolved by using different terms such as "...recovery from various and substantial disruptions...", or something like that. > >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. > > This taxonomy is going to cause confusion because it tries > to summarize in three categories what it more than three, i.e. > > > Public Private > -------------------------------------------------------------- > Commercial General Public, Enterprise Enterprise > --------------------------------------------------------------- > Gov't FTS, GETS various > ----------------------------------------------------------------- > Military DSN offnet DSN > > > Perhaps it would be better to start with just the twofold distinction > of the matrix: application (commercial, civilian Gov't, military) and > network accessibility/control (public, private). its my impression that the Charter should not be one that covers all possibilities, but rather one that identifies particular area(s) to be covered by the group at this time. It has been expressed in the past to have the group and its output expand its horizon to include potential solutions -- particularly those that one comes across in government/military networks and intranets. some of the efforts from Polk/baker/pierce represent examples of these proposed solutions that have a specific target in mind. if there is an expansion of the taxonomy, it would seem that there would be a corresponding need to identify corresponding drafts to be done. > >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. > > Should a charter reference a specific draft? Understand that > this is supposed to be an example of the previous statement > that other WGs will do the general mechanisms and requirements > and IEPREP will do specifics that pertain to emergency preparedness - > but it seems inappropriate to enshrine a specific example, > especially when it is only a draft, and likely at least to need > discussion if not being controversial in a WG charter. there is precedent to include mention of drafts into charters (see: http://www.ietf.org/html.charters/magma-charter.html). At least for initial discussion, I think its beneficial to provide an example for additional understanding, though if it causes a lot of indigestion, the final Charter for IEPREP can discard mentioning works in progress. -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Thu Jul 7 10:55:24 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14723 for ; Thu, 7 Jul 2005 10:55:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqYDt-0004Fw-OA for ieprep-archive@ietf.org; Thu, 07 Jul 2005 11:23:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqXk0-000503-9I; Thu, 07 Jul 2005 10:52:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqXjz-0004zy-IB for ieprep@megatron.ietf.org; Thu, 07 Jul 2005 10:52:39 -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 KAA14462 for ; Thu, 7 Jul 2005 10:52:37 -0400 (EDT) Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqYBB-00044W-W1 for ieprep@ietf.org; Thu, 07 Jul 2005 11:20:46 -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 j67EqR24022504; Thu, 7 Jul 2005 10:52:27 -0400 (EDT) Subject: RE: [Ieprep] Re-charter? To: "Ken Carlberg" X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Dennis Q Berg Date: Thu, 7 Jul 2005 10:52:23 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 07/07/2005 10:52:08 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: "'Ieprep'" X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Ken, Thanks for the response. - I'm ok with your approach to generalizing the outage vs. congestion issue - In making my taxonomy suggestion, I was not primarily making the comment to say that all of those possibilities should be included, but to try to clarify a classification that seemed murky and confusing. And I agree that the charter does not have to cover all possibilities, but it should be clearer than I think it is on which ones it is going to cover. Once this is done, I agree that there should be specific documents cited for any other areas. - As for citing drafts, your example of this practice is noted. If that is general practice. ok by me. 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. ---------------------------------------------------------------------------------------- "Ken Carlberg" @g11.org.uk> cc: Subject: RE: [Ieprep] Re-charter? 07/07/2005 09:41 AM > >The IEPREP WG will address proactive and > >reactive robustness and recovery from various outages using > >three perspectives: > > Why emphasize outages at the exclusion of congestions? the term outages was not meant to exclude the term congestion. this can be resolved by using different terms such as "...recovery from various and substantial disruptions...", or something like that. > >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. > > This taxonomy is going to cause confusion because it tries > to summarize in three categories what it more than three, i.e. > > > Public Private > -------------------------------------------------------------- > Commercial General Public, Enterprise Enterprise > --------------------------------------------------------------- > Gov't FTS, GETS various > ----------------------------------------------------------------- > Military DSN offnet DSN > > > Perhaps it would be better to start with just the twofold distinction > of the matrix: application (commercial, civilian Gov't, military) and > network accessibility/control (public, private). its my impression that the Charter should not be one that covers all possibilities, but rather one that identifies particular area(s) to be covered by the group at this time. It has been expressed in the past to have the group and its output expand its horizon to include potential solutions -- particularly those that one comes across in government/military networks and intranets. some of the efforts from Polk/baker/pierce represent examples of these proposed solutions that have a specific target in mind. if there is an expansion of the taxonomy, it would seem that there would be a corresponding need to identify corresponding drafts to be done. > >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. > > Should a charter reference a specific draft? Understand that > this is supposed to be an example of the previous statement > that other WGs will do the general mechanisms and requirements > and IEPREP will do specifics that pertain to emergency preparedness - > but it seems inappropriate to enshrine a specific example, > especially when it is only a draft, and likely at least to need > discussion if not being controversial in a WG charter. there is precedent to include mention of drafts into charters (see: http://www.ietf.org/html.charters/magma-charter.html). At least for initial discussion, I think its beneficial to provide an example for additional understanding, though if it causes a lot of indigestion, the final Charter for IEPREP can discard mentioning works in progress. -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Thu Jul 7 12:08:31 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21551 for ; Thu, 7 Jul 2005 12:08:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqZMf-0003Db-S6 for ieprep-archive@ietf.org; Thu, 07 Jul 2005 12:36:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqYnf-0002hi-2o; Thu, 07 Jul 2005 12:00:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqYnY-0002cz-Px for ieprep@megatron.ietf.org; Thu, 07 Jul 2005 12:00:24 -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 MAA20878 for ; Thu, 7 Jul 2005 12:00:22 -0400 (EDT) Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqZEj-0002An-6l for ieprep@ietf.org; Thu, 07 Jul 2005 12:28:32 -0400 Received: from [149.8.64.21] by mclmx2.mail.saic.com for ieprep@ietf.org; Thu, 7 Jul 2005 12:00:12 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2005070712001201924 for ; Thu, 07 Jul 2005 12:00:12 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id <33S254KW>; Thu, 7 Jul 2005 12:00:11 -0400 Message-Id: From: "King, Kimberly S." To: "Ieprep (ieprep@ietf.org)" Date: Thu, 7 Jul 2005 12:00:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.2 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: [Ieprep] Of interest X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 http://www.networkworld.com/news/2005/070705-london-explosions.html?net&stor y=070705-london-explosions&code=nlnetflash3056 "A series of about six explosions rocked London's public transport system Thursday morning, killing at least two people and injuring others. Mobile and fixed-line telephone networks were severely congested as panicked Londoners called relatives in the city, but there were no initial reports of more widespread communications damage." "There was no noticeable variation in the volume of Internet traffic through The London Internet Exchange (Linx), which manages peering points in London for all major U.K. ISPs. "With the Internet, there's been no effect," said Vanessa Evans, a spokeswoman for Linx, adding, "There's a lot of traffic flowing to the news sites, which are holding up very well." " _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Thu Jul 7 23:39:44 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00593 for ; Thu, 7 Jul 2005 23:39:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqk9g-0003u1-Ku for ieprep-archive@ietf.org; Fri, 08 Jul 2005 00:08:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqjhc-0004pA-He; Thu, 07 Jul 2005 23:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqjha-0004ow-Nj for ieprep@megatron.ietf.org; Thu, 07 Jul 2005 23:38:58 -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 XAA00579 for ; Thu, 7 Jul 2005 23:38:55 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqk8q-0003rb-2I for ieprep@ietf.org; Fri, 08 Jul 2005 00:07:09 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 07 Jul 2005 20:38:47 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,272,1115017200"; d="scan'208"; a="937109:sNHT19988652" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j683cjVu022772; Thu, 7 Jul 2005 23:38:45 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 23:38:32 -0400 Received: from jmpolk-wxp.cisco.com ([10.82.217.157]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 23:38:44 -0400 Message-Id: <4.3.2.7.2.20050707223721.0340fbb8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Jul 2005 22:38:43 -0500 To: Dennis Q Berg , "Ken Carlberg" From: "James M. Polk" Subject: RE: [Ieprep] Re-charter? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 08 Jul 2005 03:38:44.0561 (UTC) FILETIME=[8AA49410:01C5836E] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: "'Ieprep'" X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 At 10:52 AM 7/7/2005 -0400, Dennis Q Berg wrote: >- As for citing drafts, your example of this practice is noted. If that is >general practice. ok by me. I wouldn't say general practice, but it does occur when there is a basis for additional work that started in another area that stayed in that other area. >Dennis 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 From ieprep-bounces@ietf.org Thu Jul 7 23:44:54 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00916 for ; Thu, 7 Jul 2005 23:44:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqkEh-0004FT-3C for ieprep-archive@ietf.org; Fri, 08 Jul 2005 00:13:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqjl5-0005yh-MG; Thu, 07 Jul 2005 23:42:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqjl3-0005yX-Lj for ieprep@megatron.ietf.org; Thu, 07 Jul 2005 23:42:33 -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 XAA00791 for ; Thu, 7 Jul 2005 23:42:30 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqkCM-00049I-Bu for ieprep@ietf.org; Fri, 08 Jul 2005 00:10:47 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 07 Jul 2005 20:42:25 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,272,1115017200"; d="scan'208"; a="937484:sNHT22161944" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j683gNVu023482; Thu, 7 Jul 2005 23:42:23 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 23:42:11 -0400 Received: from jmpolk-wxp.cisco.com ([10.82.217.157]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 23:42:23 -0400 Message-Id: <4.3.2.7.2.20050707224150.03a0b048@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Jul 2005 22:42:22 -0500 To: "King, Kimberly S." , "Ieprep (ieprep@ietf.org)" From: "James M. Polk" Subject: Re: [Ieprep] Of interest In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 08 Jul 2005 03:42:23.0561 (UTC) FILETIME=[0D2D5390:01C5836F] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 interesting At 12:00 PM 7/7/2005 -0400, King, Kimberly S. wrote: >http://www.networkworld.com/news/2005/070705-london-explosions.html?net&stor >y=070705-london-explosions&code=nlnetflash3056 > > > >"A series of about six explosions rocked London's public transport system >Thursday morning, > > killing at least two people and injuring others. Mobile and fixed-line >telephone networks were > >severely congested as panicked Londoners called relatives in the city, but >there were no initial > > reports of more widespread communications damage." > > > >"There was no noticeable variation in the volume of Internet traffic through >The London Internet Exchange (Linx), > > which manages peering points in London for all major U.K. ISPs. > >"With the Internet, there's been no effect," said Vanessa Evans, a >spokeswoman for Linx, > >adding, "There's a lot of traffic flowing to the news sites, which are >holding up very well." " > > > >_______________________________________________ >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 From ieprep-bounces@ietf.org Wed Jul 13 10:38:55 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12270 for ; Wed, 13 Jul 2005 10:38:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsiqR-0002sW-NE for ieprep-archive@ietf.org; Wed, 13 Jul 2005 11:08:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsiMs-0000eZ-Mb; Wed, 13 Jul 2005 10:37:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsiMq-0000eU-PS for ieprep@megatron.ietf.org; Wed, 13 Jul 2005 10:37:45 -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 KAA12210 for ; Wed, 13 Jul 2005 10:37:43 -0400 (EDT) Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsipF-0002pD-1o for ieprep@ietf.org; Wed, 13 Jul 2005 11:07:07 -0400 Received: from [149.8.64.21] by mclmx2.mail.saic.com; Wed, 13 Jul 2005 10:37:33 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2005071310373319847 ; Wed, 13 Jul 2005 10:37:33 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id <3XY86JFA>; Wed, 13 Jul 2005 10:37:33 -0400 Message-Id: From: "King, Kimberly S." To: stephen.perschau@dhs.gov, "'James M. Polk'" , "King, Kimberly S." , "Ieprep (ieprep@ietf.org)" Subject: RE: [Ieprep] Of interest Date: Wed, 13 Jul 2005 10:37:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 > Interesting yes but can any conclusions be drawn I can make some observations. "Mobile and fixed-line telephone networks were severely congested as panicked Londoners called relatives in the city, but there were no initial reports of more widespread communications damage." a) It is consistently observed that disasters are correlated with heavy use of the telephone (both wireless and landline) leading to congestion in those networks. "There was no noticeable variation in the volume of Internet traffic through The London Internet Exchange (Linx), which manages peering points in London for all major U.K. ISPs" b) While flash crowds can appear at web sites, overall the Internet volume in the local area seems to have been fairly normal. Now, there is an expectation that much landline voice will move from circuit-switched networks to VoIP transport over the public Internet. Thus one could postulate that emergencies will result in higher volume of VoIP in the disaster area. This brings to mind a couple of concerns. c) What can be expected about call quality of any type of call traversing the public Internet in the disaster area? d) What does this imply for the Internet health in this local area given that VoIP tends to use UDP which doesn't back off nicely in light of congestion? Yes, people are working in this area and I can see why. Kimberly _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Wed Jul 13 17:21:47 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15051 for ; Wed, 13 Jul 2005 17:21:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dsp8O-0002xO-16 for ieprep-archive@ietf.org; Wed, 13 Jul 2005 17:51:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsoeL-0007LC-P0; Wed, 13 Jul 2005 17:20:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsoeK-0007L2-5j for ieprep@megatron.ietf.org; Wed, 13 Jul 2005 17:20:12 -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 RAA14925 for ; Wed, 13 Jul 2005 17:20:09 -0400 (EDT) Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dsp6n-0002tE-Ux for ieprep@ietf.org; Wed, 13 Jul 2005 17:49:38 -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 j6DLK8S3012985 for ; Wed, 13 Jul 2005 17:20:08 -0400 (EDT) In-Reply-To: Subject: Re: [Ieprep] re-charter To: ieprep@ietf.org X-Mailer: Lotus Notes 652HF83 November 04, 2004 Message-ID: From: Richard F Kaczmarek Date: Wed, 13 Jul 2005 17:19:58 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 07/13/2005 05:19:56 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 I think rechartering the ieprep wg is a good idea. In rechartering, I would like the group to consider the following. Based upon testing of IP/GSTN interoperability under conditions of congestion, there are a number of IP network requirements and mechanisms needed to ensure a GETS-like service works across a congested IP network. For example, fidelity of DTMF tones for PIN authentication is an issue at high utilizations. The requirements associated with emergency communications (e.g., a GETS-like service) fall into four broad categories: 1. Signaling. Signaling requirements can be divided into two types: (a) Signaling a request for emergency communications to an authentication / authorization entity for approval, and (b) Signaling an authorized / authenicated request from the source to destination. Within the IP network, SIP was found to be resilient in the face of congestion, so no distinction may be required between the two signaling types. However, the delays associated with SIP under heavy congestion impacted its successful interoperation with SS7 signaling in the PSTN. 2. Resource Provisioning. Providing the necessary resources for authenticated emergency communications. With G711 codecs, VoIP was found to be intelligible up to an offered load of 150% of the bottleneck link capacity. Thus a Call Admission Control mechanism that allows for "oversubscription" for emergency communications may be appropriate (e.g., CAC set to 80% of link capacity, with emergency communications allowed an additional 10% of link capacity). If oversubscription is not acceptable, guaranteed bandwith is also possible. With the Cisco routers we were using, we could allocate bandwidth in the EF queue for emergency communications and for normal traffic. In this latter case, some sort of marker (e.g., DSCP) may be needed for emergency traffic, but a unique per hop behavior may not be needed. 3. Security. Issues include authentication within the IP network and across network boundaries. In particular, if a GETS-like service is authenticated in the GSTN through DTMF tones transmitted across the IP network (as is currently done), there are issues of PIN intercept and PIN transmission errors associated with delayed and dropped packets at high utilizations. RFC 2833 and the KeyPad Markup Language (KPML) may provide solutions. A second issue concerns inter-domain trust to allow "prioritization" of emergency communications end-to-end, both between IP domains, and between IP and GSTN domains. 4. Network engineering and provisioning "best practices." For example, for IP/GSTN interoperation, the number of SIP retries should be set to "x." While the documents already produced by the ieprep wg address, at varying levels, many of these areas, there are additional "GETS-like" service-unique requirements that are not documented. It is likely that a majority of these additional requirements can be satisfied by using the mechanisms (being) developed by the other working groups. As such, I believe the charter should allow for the creation of additional "to be specified" I-D documents by the working group. If this is allowed and the working group is rechartered, then I am willing to work in the group to define and create the appropriate documents discussing the "GETS-like" requirements, mechanisms and best practices. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Wed Jul 13 19:04:29 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23442 for ; Wed, 13 Jul 2005 19:04:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dsqjm-0006Jc-VA for ieprep-archive@ietf.org; Wed, 13 Jul 2005 19:33:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsqFA-0007Rz-VV; Wed, 13 Jul 2005 19:02:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsqFA-0007RS-99 for ieprep@megatron.ietf.org; Wed, 13 Jul 2005 19:02:20 -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 TAA23324 for ; Wed, 13 Jul 2005 19:02:16 -0400 (EDT) Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dsqha-0006G3-Tb for ieprep@ietf.org; Wed, 13 Jul 2005 19:31:46 -0400 X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-4.tower-121.messagelabs.com!1121295723!3240966!2 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.133.132] Received: (qmail 23748 invoked from network); 13 Jul 2005 23:02:05 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (192.128.133.132) by server-4.tower-121.messagelabs.com with SMTP; 13 Jul 2005 23:02:05 -0000 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.13) by attrh3i.attrh.att.com (7.2.052) id 42BED276003537BF; Wed, 13 Jul 2005 19:02:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ieprep] re-charter Date: Wed, 13 Jul 2005 18:02:05 -0500 Message-ID: <28F05913385EAC43AF019413F674A0170A4131B2@OCCLUST04EVS1.ugd.att.com> Thread-Topic: [Ieprep] re-charter Thread-Index: AcWH8Lj/l7yECkWgSpadi3JARnp0fwADWILQ From: "Dolly, Martin C, ALABS" To: "Richard F Kaczmarek" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: quoted-printable X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable Hello Dick, The items that you listed are already being addressed by ATIS-PTSC and ITU. If a new IP capability or extension (e.g., RPH) is needed, then draft(s) will be submitted to the IETF. Cheers, Martin > -----Original Message----- > From: ieprep-bounces@ietf.org=20 > [mailto:ieprep-bounces@ietf.org]On Behalf > Of Richard F Kaczmarek > Sent: Wednesday, July 13, 2005 5:20 PM > To: ieprep@ietf.org > Subject: Re: [Ieprep] re-charter >=20 >=20 >=20 >=20 >=20 >=20 > I think rechartering the ieprep wg is a good idea. In=20 > rechartering, I would > like the group to consider the following. >=20 > Based upon testing of IP/GSTN interoperability under conditions of > congestion, there are a number of IP network requirements and=20 > mechanisms > needed to ensure a GETS-like service works across a congested=20 > IP network. > For example, fidelity of DTMF tones for PIN authentication is=20 > an issue at > high utilizations. >=20 > The requirements associated with emergency communications (e.g., a > GETS-like service) fall into four broad categories: >=20 > 1. Signaling. Signaling requirements can be divided into two=20 > types: (a) > Signaling a request for emergency communications to an=20 > authentication / > authorization entity for approval, and (b) Signaling an authorized / > authenicated request from the source to destination. Within=20 > the IP network, > SIP was found to be resilient in the face of congestion, so=20 > no distinction > may be required between the two signaling types. However, the delays > associated with SIP under heavy congestion impacted its successful > interoperation with SS7 signaling in the PSTN. >=20 > 2. Resource Provisioning. Providing the necessary resources for > authenticated emergency communications. With G711 codecs,=20 > VoIP was found to > be intelligible up to an offered load of 150% of the bottleneck link > capacity. Thus a Call Admission Control mechanism that allows for > "oversubscription" for emergency communications may be=20 > appropriate (e.g., > CAC set to 80% of link capacity, with emergency=20 > communications allowed an > additional 10% of link capacity). If oversubscription is not=20 > acceptable, > guaranteed bandwith is also possible. With the Cisco routers=20 > we were using, > we could allocate bandwidth in the EF queue for emergency=20 > communications > and for normal traffic. In this latter case, some sort of=20 > marker (e.g., > DSCP) may be needed for emergency traffic, but a unique per=20 > hop behavior > may not be needed. >=20 > 3. Security. Issues include authentication within the IP=20 > network and across > network boundaries. In particular, if a GETS-like service is=20 > authenticated > in the GSTN through DTMF tones transmitted across the IP=20 > network (as is > currently done), there are issues of PIN intercept and PIN=20 > transmission > errors associated with delayed and dropped packets at high=20 > utilizations. > RFC 2833 and the KeyPad Markup Language (KPML) may provide=20 > solutions. A > second issue concerns inter-domain trust to allow "prioritization" of > emergency communications end-to-end, both between IP domains,=20 > and between > IP and GSTN domains. >=20 > 4. Network engineering and provisioning "best practices." For=20 > example, for > IP/GSTN interoperation, the number of SIP retries should be=20 > set to "x." >=20 > While the documents already produced by the ieprep wg=20 > address, at varying > levels, many of these areas, there are additional "GETS-like" > service-unique requirements that are not documented. It is=20 > likely that a > majority of these additional requirements can be satisfied by=20 > using the > mechanisms (being) developed by the other working groups. >=20 > As such, I believe the charter should allow for the creation=20 > of additional > "to be specified" I-D documents by the working group. If this=20 > is allowed > and the working group is rechartered, then I am willing to work in the > group to define and create the appropriate documents discussing the > "GETS-like" requirements, mechanisms and best practices. >=20 >=20 > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep >=20 _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Fri Jul 15 16:38:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtWwr-0008GZ-B2; Fri, 15 Jul 2005 16:38:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtWwp-0008DX-FE; Fri, 15 Jul 2005 16:38:15 -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 QAA01610; Fri, 15 Jul 2005 16:38:10 -0400 (EDT) Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtXPd-0006xU-NR; Fri, 15 Jul 2005 17:08:04 -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 j6FKbp1h004329; Fri, 15 Jul 2005 16:37:59 -0400 (EDT) In-Reply-To: Subject: Re: [Ieprep] re-charter To: ken carlberg X-Mailer: Lotus Notes 652HF83 November 04, 2004 Message-ID: From: Janet P Gunn Date: Fri, 15 Jul 2005 16:25:17 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 07/15/2005 04:37:46 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: ieprep-bounces@ietf.org, ieprep@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org ieprep-bounces@ietf.org wrote on 07/14/2005 03:48:57 PM: > > On Jul 13, 2005, at 5:19 PM, Richard F Kaczmarek wrote: > > > > > > With the Cisco routers we were using, > > we could allocate bandwidth in the EF queue for emergency > > communications > > and for normal traffic. In this latter case, some sort of marker > > (e.g., > > DSCP) may be needed for emergency traffic, but a unique per hop > > behavior > > may not be needed. > > for this last sentence, if what you are advocating is defining > another DSCP value but with no distinctive corresponding per hop > behavior, then I think that is a non-starter. > >From RFC 3246 " Finally, it is possible to implement hierarchical scheduling algorithms, such that some non-FIFO scheduling algorithm is run on sub-flows within the EF aggregate, while the EF aggregate as a whole could be served at high priority or with a large weight by the top- level scheduler. Such an algorithm might perform per-input scheduling or per-microflow scheduling within the EF aggregate, for example. " This is one way of describing the functionality above. Also from RFC 3246 "It should be noted that it is quite acceptable for a Diffserv domain to provide multiple instances of EF. Each instance should be characterizable by the equations in Section 2.2 of this specification. The effect of having multiple instances of EF on the E_a and E_p values of each instance will depend considerably on how the multiple instances are implemented. For example, in a multi- level priority scheduler, an instance of EF that is not at the highest priority may experience relatively long periods when it receives no service while higher priority instances of EF are served. This would result in relatively large values of E_a and E_p. By contrast, in a WFQ-like scheduler, each instance of EF would be represented by a queue served at some configured rate and the values of E_a and E_p could be similar to those for a single EF instance." And at the San Diego meeting, one of the authors of RFC 3246 (sorry, I forget who) explicitly said in his presentation that there was never any intention to restrict EF to a single DSCP. There do, of course, remain issues as to whether it is a good idea or not. But it is permissible under RFC 3246. Janet _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Fri Jul 15 17:08:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtXQU-0001P4-IY; Fri, 15 Jul 2005 17:08:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtXQQ-0001OH-Ou for ieprep@megatron.ietf.org; Fri, 15 Jul 2005 17:08:50 -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 RAA14526 for ; Fri, 15 Jul 2005 17:08:46 -0400 (EDT) Received: from hermes.hosts.co.uk ([212.84.175.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtXtF-00037N-4N for ieprep@ietf.org; Fri, 15 Jul 2005 17:38:40 -0400 Received: from [69.138.71.61] (helo=[192.168.1.101]) by hermes.hosts.co.uk with esmtpa (Exim 4.44) id 1DtXTf-0001l4-2t; Fri, 15 Jul 2005 22:12:21 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <804511E4-CD31-48C8-B2BD-E668CD0B849A@g11.org.uk> Content-Transfer-Encoding: 7bit From: ken carlberg Subject: Re: [Ieprep] re-charter Date: Fri, 15 Jul 2005 17:08:01 -0400 To: Janet P Gunn X-Mailer: Apple Mail (2.733) X-Spam-Score: 2.0 (++) X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Cc: ieprep@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org ok, then you are advocating a particular realization of EF as stipulated in rfc3246, as opposed to a new DSCP. thanks for the clarification. -ken On Jul 15, 2005, at 4:25 PM, Janet P Gunn wrote: > >> >> On Jul 13, 2005, at 5:19 PM, Richard F Kaczmarek wrote: >> >> >>> >>> >> >> >>> With the Cisco routers we were using, >>> we could allocate bandwidth in the EF queue for emergency >>> communications >>> and for normal traffic. In this latter case, some sort of marker >>> (e.g., >>> DSCP) may be needed for emergency traffic, but a unique per hop >>> behavior >>> may not be needed. >>> >> >> for this last sentence, if what you are advocating is defining >> another DSCP value but with no distinctive corresponding per hop >> behavior, then I think that is a non-starter. >> >> > > >> From RFC 3246 >> > " Finally, it is possible to implement hierarchical scheduling > algorithms, such that some non-FIFO scheduling algorithm is run on > sub-flows within the EF aggregate, while the EF aggregate as a > whole > could be served at high priority or with a large weight by the top- > level scheduler. Such an algorithm might perform per-input > scheduling or per-microflow scheduling within the EF aggregate, for > example. " > > This is one way of describing the functionality above. > > Also from RFC 3246 > "It should be noted that it is quite acceptable for a Diffserv domain > to provide multiple instances of EF. Each instance should be > characterizable by the equations in Section 2.2 of this > specification. The effect of having multiple instances of EF on > the > E_a and E_p values of each instance will depend considerably on how > the multiple instances are implemented. For example, in a multi- > level priority scheduler, an instance of EF that is not at the > highest priority may experience relatively long periods when it > receives no service while higher priority instances of EF are > served. > This would result in relatively large values of E_a and E_p. By > contrast, in a WFQ-like scheduler, each instance of EF would be > represented by a queue served at some configured rate and the > values > of E_a and E_p could be similar to those for a single EF instance." > > And at the San Diego meeting, one of the authors of RFC 3246 (sorry, I > forget who) explicitly said in his presentation that there was > never any > intention to restrict EF to a single DSCP. > > > There do, of course, remain issues as to whether it is a good idea > or not. > But it is permissible under RFC 3246. > > Janet > > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Tue Jul 19 11:34:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duu7U-0000vn-5u; Tue, 19 Jul 2005 11:34:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duu7S-0000qk-3d for ieprep@megatron.ietf.org; Tue, 19 Jul 2005 11:34:54 -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 LAA06930 for ; Tue, 19 Jul 2005 11:34:51 -0400 (EDT) Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Duub5-0008Od-3d for ieprep@ietf.org; Tue, 19 Jul 2005 12:05:33 -0400 Received: from [149.8.64.21] by mclmx.mail.saic.com; Tue, 19 Jul 2005 11:34:34 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2005071911343119375 ; Tue, 19 Jul 2005 11:34:33 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Tue, 19 Jul 2005 11:34:30 -0400 Message-Id: From: "King, Kimberly S." To: an.p.nguyen@dhs.gov, "King, Kimberly S." Subject: RE: [Ieprep] Re-charter? Date: Tue, 19 Jul 2005 11:33:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: sob@harvard.edu, "Ieprep \(ieprep@ietf.org\)" X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org An, >>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. >I notice some solutions to providing the priority of traffic in association >with QoS have been addressed in NSIS. >I would like to how RSVP extensions can be used to address these >requirements. The intended charter isn't to presuppose a solution. The above was an example of what might be in scope and a practical avenue for progress within the group. Since you have asked me about "how" extensions could be used, off hand I'd point to RFC 2750, but again the charter discussion is not to discuss exact solutions so let's leave it at that until it is decided what should be done. Kimberly _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep