From mailman-bounces@ietf.org Wed Jun 1 06:43:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29321 for ; Wed, 1 Jun 2005 06:43:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdR1R-00031f-EG for ieprep-archive@ietf.org; Wed, 01 Jun 2005 07:04:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdPAI-0005hK-8Q for ieprep-archive@ietf.org; Wed, 01 Jun 2005 05:05:30 -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: Wed, 01 Jun 2005 05:01:43 -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 Thu Jun 30 10:26: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 KAA18019 for ; Thu, 30 Jun 2005 10:26:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do0Pv-00082W-VT for ieprep-archive@ietf.org; Thu, 30 Jun 2005 10:53:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnzyJ-0006e8-Id; Thu, 30 Jun 2005 10:24:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnzyH-0006b1-TK for ieprep@megatron.ietf.org; Thu, 30 Jun 2005 10:24: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 KAA17895 for ; Thu, 30 Jun 2005 10:24:51 -0400 (EDT) Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do0O2-0007xF-W6 for ieprep@ietf.org; Thu, 30 Jun 2005 10:51:32 -0400 Received: from [149.8.64.21] by mclmx.mail.saic.com; Thu, 30 Jun 2005 10:24:29 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2005063010242918055 ; Thu, 30 Jun 2005 10:24:29 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Thu, 30 Jun 2005 10:24:28 -0400 Message-Id: From: "King, Kimberly S." To: "Ieprep (ieprep@ietf.org)" Date: Thu, 30 Jun 2005 10:24:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.8 (/) X-Scan-Signature: 2d1100b36d83fed07afbc292d8848e10 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: sob@harvard.edu, "Jon Peterson \(jon.peterson@neustar.biz\)" Subject: [Ieprep] Re-charter? 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: 0e9ebc0cbd700a87c0637ad0e2c91610 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 From ieprep-bounces@ietf.org Thu Jun 30 10:51:23 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 KAA20128 for ; Thu, 30 Jun 2005 10:51:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do0nj-0006GM-PA for ieprep-archive@ietf.org; Thu, 30 Jun 2005 11:18:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do0Ks-0005jU-Rr; Thu, 30 Jun 2005 10:48:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do0Ks-0005jP-4H for ieprep@megatron.ietf.org; Thu, 30 Jun 2005 10:48: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 KAA19796 for ; Thu, 30 Jun 2005 10:48:12 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do0kd-00038o-Iu for ieprep@ietf.org; Thu, 30 Jun 2005 11:14:52 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j5UEm8mD010243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Jun 2005 10:48:09 -0400 (EDT) Message-ID: <42C40623.7010303@cs.columbia.edu> Date: Thu, 30 Jun 2005 10:48:03 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "King, Kimberly S." Subject: Re: [Ieprep] Re-charter? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: "Jon Peterson \(jon.peterson@neustar.biz\)" , 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit 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