From mailman-owner@ietf.org Fri Feb 1 06:43:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18261 for ; Fri, 1 Feb 2002 06:43:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA01075 for ; Fri, 1 Feb 2002 06:43:48 -0500 (EST) Date: Fri, 1 Feb 2002 06:43:48 -0500 (EST) Message-Id: <200202011143.GAA01075@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: ieprep-web-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol 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, ieprep-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for ieprep-web-archive@ietf.org: List Password // URL ---- -------- ieprep@ietf.org fPSM https://www1.ietf.org/mailman/options/ieprep/ieprep-web-archive@ietf.org From ieprep-admin@ietf.org Fri Feb 1 13:14:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06433 for ; Fri, 1 Feb 2002 13:14:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01719; Fri, 1 Feb 2002 13:14:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01681 for ; Fri, 1 Feb 2002 13:14:31 -0500 (EST) Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06427 for ; Fri, 1 Feb 2002 13:14:27 -0500 (EST) Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Feb 2002 13:14:30 -0500 Message-ID: From: "Folts, Harold" To: "IEPS List (E-mail)" , "ieprep List (E-mail)" Date: Fri, 1 Feb 2002 13:14:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1AB4C.49D710A0" Subject: [Ieprep] Revised ID Submitted Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1AB4C.49D710A0 Content-Type: text/plain; charset="iso-8859-1" I have sent in the revised ID presenting my white paper on ETS - draft-folts-ieps-white-paper-01.txt. You can get an advance copy from www.iepscheme.net. There are many significant changes from the -00 version. Hal <> ------_=_NextPart_000_01C1AB4C.49D710A0 Content-Type: application/octet-stream; name="Hal Folts - NCS (E-mail).vcf" Content-Disposition: attachment; filename="Hal Folts - NCS (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:;Hal Folts - NCS FN:Hal Folts - NCS (E-mail) EMAIL;PREF;INTERNET:foltsh@ncs.gov REV:20020104T144212Z END:VCARD ------_=_NextPart_000_01C1AB4C.49D710A0-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Feb 7 22:38:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18938 for ; Thu, 7 Feb 2002 22:38:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03365; Thu, 7 Feb 2002 22:33:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03333 for ; Thu, 7 Feb 2002 22:33:07 -0500 (EST) Received: from web20805.mail.yahoo.com (web20805.mail.yahoo.com [216.136.226.194]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA18894 for ; Thu, 7 Feb 2002 22:33:03 -0500 (EST) Message-ID: <20020208033304.83373.qmail@web20805.mail.yahoo.com> Received: from [134.193.6.56] by web20805.mail.yahoo.com via HTTP; Thu, 07 Feb 2002 19:33:04 PST Date: Thu, 7 Feb 2002 19:33:04 -0800 (PST) From: senthil ayyasamy To: ieprep@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Ieprep] implementation issues Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org Hi all, This question is regarding implementaion issues regarding IEPS. It seems to me that implementing IEPS requires remodeling many protocols at various levels in the TCP/IP stack . The very simple case of modifying the DS codepoint (to include priority) will require changes in many TCP/IP protocols. Can't it be possible to work on the existing protocol standard with minimum modifications ( maybe make changes at one particular layer )? Thanks in advance. - senthil ===== SENTHIL KUMAR MS(COMPUTER NETWORKING) UMKC, MO-64112,USA __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Feb 8 03:40:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01223 for ; Fri, 8 Feb 2002 03:40:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA24192; Fri, 8 Feb 2002 03:40:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA24156 for ; Fri, 8 Feb 2002 03:40:36 -0500 (EST) Received: from rbhub100.chamb.disa.mil (rbhub100.chamb.disa.mil [209.22.120.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01218 for ; Fri, 8 Feb 2002 03:40:33 -0500 (EST) Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id <12JDLDM3>; Fri, 8 Feb 2002 03:40:35 -0500 Message-ID: From: "Folts, Harold" To: "ieprep List (E-mail)" , "IEPS List (E-mail)" Date: Fri, 8 Feb 2002 03:40:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1B07C.455CFDC0" Subject: [Ieprep] Proposed IETF Working Group - ieprep Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1B07C.455CFDC0 Content-Type: text/plain; charset="iso-8859-1" Greetings, Earlier this week the IESG announced that establishment of a new working group is proposed - internet emergency preparedness (ieprep). Based upon comments received, the IESG will make the decision for approval. The IESG announcement and proposed charter is below. A BOF for ieprep is on the agenda for IETF 53 in Minneapolis next month 3:30-5:30 pm. We expect to discuss the charter, further discuss the issues, and plan a path ahead. ---------------------------------------------------------------------------- ------- Copy of the announcement and Proposed Charter: A new working group has been proposed in the Transport Area of the IETF. The IESG has not made any determination as yet. The following Description was submitted, and is provided for informational purposes only: Internet Emergency Preparedness (ieprep) ---------------------------------------- Current Status: Proposed Working Group Description of Working Group: Effective telecommunications capabilities are imperative to facilitate immediate recovery operations for serious disaster events, such as, hurricanes, floods, earthquakes, and terrorist attacks. 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. Three examples of emergency communications include: 1. Conveying information about the priority of specific phone calls that originate in a VoIP environment through gateways to the PSTN. 2. Access and transport for database and information distribution applications relevant to managing the crisis. One example of this is the I am Alive (IAA) system that can be used by people in a disaster zone to register the fact that they are alive so that their friends and family can check on their health. 3. Interpersonal communication among crisis management personnel using electronic mail and instant messaging. Initial documents will describe the problem space and its salient characteristics. In particular the working group will devlop a Requirements for Internet Emergency Preparedness in the Internet RFC which will detail the specific functions and technologies needed to provide support for Emergency Preparedness systems in the Internet. The working group may also develop a Framework for Supporting Internet Emergency Preparedness in IP Telephony RFC if it is determined that IP telephony requires special treatment above what would be in the requirements document. The international community needs advice as to what standards to rely on, in the form of a BCP. This BCP needs to identify mechanisms to provide deterministic behavior of applications, mechanisms for authentication and authorization, and recommendations for application design with existing protocols. 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, Differentiated Services, Protocol for carrying Authentication for Network Access (pana), and various operational groups, so the IEPREP working group will have to cooperate closely with these groups and with groups outside of the IETF such as various ITU-T study groups. The working group will develop a BCP RFC or set of RFCs, regarding operational implementation of services for Emergency Preparedness using existing Internet protocols. The RFC may include identification of gaps in existing protocols and requirements for use in new protocol or protocol feature design. It is out of scope for this working group to do protocol or protocol feature development. The working group will not focus on particular national regulations. Deliverables Best Current Practice: IETF Recommendations for the Emergency Telecommunications Service using existing protocols - what can be done with existing protcols and what can not be done. Informationals: Requirements for Internet Emergency Preparedness in the Internet. Framework for Supporting Internet Emergency Preparedness in IP Telephony. ---------------------------------------------------------------------------- --------- Hal <> ------_=_NextPart_000_01C1B07C.455CFDC0 Content-Type: application/octet-stream; name="Folts, Hal.vcf" Content-Disposition: attachment; filename="Folts, Hal.vcf" BEGIN:VCARD VERSION:2.1 N;ENCODING=QUOTED-PRINTABLE:;=01 REV:20010930T194720Z END:VCARD ------_=_NextPart_000_01C1B07C.455CFDC0-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Feb 8 04:21:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01873 for ; Fri, 8 Feb 2002 04:21:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25564; Fri, 8 Feb 2002 04:21:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25531 for ; Fri, 8 Feb 2002 04:21:07 -0500 (EST) Received: from rbhub100.chamb.disa.mil (rbhub100.chamb.disa.mil [209.22.120.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01867 for ; Fri, 8 Feb 2002 04:21:04 -0500 (EST) Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id <12JDLD4L>; Fri, 8 Feb 2002 04:21:07 -0500 Message-ID: From: "Folts, Harold" To: "ieprep List (E-mail)" , "IEPS List (E-mail)" Date: Fri, 8 Feb 2002 04:21:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1B081.EF6D9310" Subject: [Ieprep] List Clarification Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1B081.EF6D9310 Content-Type: text/plain; charset="iso-8859-1" I want to clarify the purpose for the two above lists that address the emergency communications issues. the original list used over the past two years is - ieps@listserv.gsfc.nasa.gov A new list was established by the IETF in December after the BOF on ieprep - ieprep@ietf.org All the names on the ieps list were copied to the newly established ieprep list. Therefore, many are on both lists. The ieprep list is intended for the detailed online discussions of the issues specifically for the ieprep work in the IETF. Recognizing that there is also work on non-IETF aspects of the Emergency Telecommunications Service is also in other standards bodies - (ITU-T, ETSI, TMForum, and the US T1 subcommittees, the ieps list will continue for the purpose of status and discussion issues of the specific areas. You may subscribe or unsubscribe for these lists as follows: ieprep@ietf.org - send email to: ietf-announce-request@ietf.org - to unsubscribe enter the word in the body - unsubscribe (no other text) to subscribe enter the word in both subject and body - subscribe (no other text) ieps@listserv.gsfc.nasa.gov - sent email to majordomo@listserv.gsfc.nasa.gov to unsubscribe enter the word in body - unsubscribe ieps (no other text) to subscribe enter the word in body - subscribed ieps (no other text) I am will continue to maintain the ieps web site: www.iepscheme.net to provide information and various working documents. Please let me know if you have any questions. Regards, Hal Folts <> ------_=_NextPart_000_01C1B081.EF6D9310 Content-Type: application/octet-stream; name="Folts, Hal.vcf" Content-Disposition: attachment; filename="Folts, Hal.vcf" BEGIN:VCARD VERSION:2.1 N;ENCODING=QUOTED-PRINTABLE:;=01 REV:20010930T194720Z END:VCARD ------_=_NextPart_000_01C1B081.EF6D9310-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Feb 8 04:26:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01949 for ; Fri, 8 Feb 2002 04:26:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25787; Fri, 8 Feb 2002 04:26:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25753 for ; Fri, 8 Feb 2002 04:26:19 -0500 (EST) Received: from rbhub100.chamb.disa.mil (rbhub100.chamb.disa.mil [209.22.120.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01930 for ; Fri, 8 Feb 2002 04:26:16 -0500 (EST) Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id <12JDLDVS>; Fri, 8 Feb 2002 04:26:18 -0500 Message-ID: From: "Folts, Harold" To: "IEPS List (E-mail)" , "ieprep List (E-mail)" Date: Fri, 8 Feb 2002 04:26:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1B082.A9300C60" Subject: [Ieprep] ETSI EMTEL Workshop Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1B082.A9300C60 Content-Type: text/plain; charset="iso-8859-1" The European Telecommunications Standards Institute (ETSI) is holding a workshop on emergency telecommunications EMTEL February 26-27 in Sofia Antipolis, France. Visit: www.emtel.etsi.org for further information. Hal ------_=_NextPart_000_01C1B082.A9300C60 Content-Type: application/octet-stream; name="Folts, Hal.vcf" Content-Disposition: attachment; filename="Folts, Hal.vcf" BEGIN:VCARD VERSION:2.1 N;ENCODING=QUOTED-PRINTABLE:;=01 REV:20010930T194720Z END:VCARD ------_=_NextPart_000_01C1B082.A9300C60-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Feb 8 09:23:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07580 for ; Fri, 8 Feb 2002 09:23:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09611; Fri, 8 Feb 2002 09:20:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09577 for ; Fri, 8 Feb 2002 09:20:48 -0500 (EST) Received: from rbhub100.chamb.disa.mil (rbhub100.chamb.disa.mil [209.22.120.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07468 for ; Fri, 8 Feb 2002 09:20:44 -0500 (EST) Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id <12JDL2PM>; Fri, 8 Feb 2002 09:20:43 -0500 Message-ID: From: "Folts, Harold" To: "'ieprep List (E-mail)'" , "'IEPS List (E-mail)'" Date: Fri, 8 Feb 2002 09:20:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1B0AB.C97B6D10" Subject: [Ieprep] List Clarification Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1B0AB.C97B6D10 Content-Type: text/plain; charset="iso-8859-1" Sorry, I left out some important information in this earlier email for subscribing/unsubscribing from the ieprep list. See correct information below ---------------------------------------------------------------------------- ---------------------- I want to clarify the purpose for the two above lists that address the emergency communications issues. the original list used over the past two years is - ieps@listserv.gsfc.nasa.gov A new list was established by the IETF in December after the BOF on ieprep - ieprep@ietf.org All the names on the ieps list were copied to the newly established ieprep list. Therefore, many are on both lists. The ieprep list is intended for the detailed online discussions of the issues specifically for the ieprep work in the IETF. Recognizing that there is also work on non-IETF aspects of the Emergency Telecommunications Service is also in other standards bodies - (ITU-T, ETSI, TMForum, and the US T1 subcommittees, the ieps list will continue for the purpose of status and discussion issues of the specific areas. You may subscribe or unsubscribe for these lists as follows: ieprep@ietf.org - send email to: ietf-announce-request@ietf.org - to unsubscribe enter the word in the body - unsubscribe ieprep(no other text) to subscribe enter the word in both subject and body - subscribe ieprep (no other text) ieps@listserv.gsfc.nasa.gov - sent email to majordomo@listserv.gsfc.nasa.gov to unsubscribe enter the word in body - unsubscribe ieps (no other text) to subscribe enter the word in body - subscribed ieps (no other text) I am will continue to maintain the ieps web site: www.iepscheme.net to provide information and various working documents. Please let me know if you have any questions. Regards, Hal Folts <> ------_=_NextPart_000_01C1B0AB.C97B6D10 Content-Type: application/octet-stream; name="Folts, Hal.vcf" Content-Disposition: attachment; filename="Folts, Hal.vcf" BEGIN:VCARD VERSION:2.1 N;ENCODING=QUOTED-PRINTABLE:;=01 REV:20010930T194720Z END:VCARD ------_=_NextPart_000_01C1B0AB.C97B6D10-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sat Feb 9 15:43:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19570 for ; Sat, 9 Feb 2002 15:43:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02469; Sat, 9 Feb 2002 15:41:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02435 for ; Sat, 9 Feb 2002 15:41:22 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19541 for ; Sat, 9 Feb 2002 15:41:20 -0500 (EST) Received: from FRED-W2K6.cisco.com ([171.71.21.235] (may be forged)) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA08478; Sat, 9 Feb 2002 12:40:49 -0800 (PST) Message-Id: <4.3.2.7.2.20020209122528.021cd7e8@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 09 Feb 2002 12:40:12 -0800 To: "Folts, Harold" From: Fred Baker Cc: "ieprep List (E-mail)" , "IEPS List (E-mail)" , Scott Bradner In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ieprep] Re: Proposed IETF Working Group - ieprep Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org At 12:40 AM 2/8/2002, Folts, Harold wrote: >A BOF for ieprep is on the agenda for IETF 53 in Minneapolis next month >3:30-5:30 pm. We expect to discuss the charter, further discuss the issues, >and plan a path ahead. that is in fact incorrect. A working group has been chartered, and you posted the announcement of its charter. I am the chair, and there will be a co-chair when the IESG appoints one. What will be meeting at that time is the first meeting of the working group. The charter of the working group is limited, and the plan is to complete a its tasks fairly quickly - by the end of summer. If as a result of that it is clear that additional work is required, the IESG will revise the charter. The charter of the working group might be summarized in this way: - we need a gap analysis between the PSTN and the various protocols used in VoIP, so that we can determine what differences may be relevant in an emergency situation. - where the gap analysis shows deficiencies (and we already know that deficiencies exist, such as the lack of an information element identifying an emergency call), our responsibility is to document them. Resolving them is the responsibility of the relevant WG. - In addition, various services have been proposed using the data capabilities of the network. We need to perform a gap analysis to ensure that the data network in fact adequately supports those applications. - ultimately, we need to provide some advice to those who might contract or deploy e911-style services, so that design expectations are set all around. I am putting together an agenda for the first meeting now, and would like folks who want agenda time to address these issues to contact me privately. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sun Feb 10 06:52:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05663 for ; Sun, 10 Feb 2002 06:52:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA07740; Sun, 10 Feb 2002 06:51:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA07708 for ; Sun, 10 Feb 2002 06:51:47 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05660 for ; Sun, 10 Feb 2002 06:51:44 -0500 (EST) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 10 Feb 2002 11:41:52 +0000 X-Mailer: exmh version 2.4 05/15/2001 with version: MH 6.8.3 #25[UCI] To: mplsgeek@yahoo.com cc: ieprep@ietf.org Subject: Re: [Ieprep] implementation issues (fwd) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 10 Feb 2002 11:41:51 +0000 Message-ID: <614.1013341311@cs.ucl.ac.uk> From: Ken Carlberg Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org > This question is regarding implementaion issues > regarding IEPS. It seems to me that implementing IEPS > requires remodeling many protocols at various levels > in the TCP/IP stack . ouch. the above observation can be a bit dangerous because it takes on too much. Its ok if one starts from scratch in thinking how one addresses support of emergency-related flows. But, its been argued that one needs a problem or a set of requirements constituting an objective (a problem to be resolved) before assuming the extent of "remodeling many protocols". (and of course, some may argue nothing needs to be done). on the other side of the spectrum, a per-application, per-transport, per-network, and any combination thereof, examination would also seem to be quite a challenge and may be to large a problem space. i think classifying groups of applications along the lines of tcp-based (short or long lived), transaction oriented, and udp-based interactive is a bit easier. it may not be perfect, and examples of exceptions may slip through, but it makes the problem space easier. > The very simple case of > modifying the DS codepoint (to include priority) will > require changes in many TCP/IP protocols. why would it require changes? outside of that. some folks contend that the existing code points can be used to satisfy emergency communications (at least with respect to the specific problem of IP telephony). see the Baker draft and Pierce draft, which include an example approach. http://search.ietf.org/internet-drafts/draft-baker-ieps-requirements-00.txt http://search.ietf.org/internet-drafts/draft-pierce-sipping-assured-service -00.txt > Can't it be > possible to work on the existing protocol standard > with minimum modifications ( maybe make changes at one > particular layer )? did you have a layer in mind? it may be possible, and i certainly wouldn't want to discourage work to try and accomplish it. but you may want to ask yourself if the layer (or sub-layer) you choose applies to the types of applications and their underlying transport protocols can be supported. -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sun Feb 10 16:17:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10849 for ; Sun, 10 Feb 2002 16:17:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24405; Sun, 10 Feb 2002 16:14:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24371 for ; Sun, 10 Feb 2002 16:14:09 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10833 for ; Sun, 10 Feb 2002 16:14:06 -0500 (EST) Received: from FRED-W2K6.cisco.com ([171.71.21.235] (may be forged)) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA14158; Sun, 10 Feb 2002 13:13:37 -0800 (PST) Message-Id: <4.3.2.7.2.20020210123613.022e5298@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 10 Feb 2002 12:40:29 -0800 To: senthil ayyasamy From: Fred Baker Subject: Re: [Ieprep] implementation issues Cc: ieprep@ietf.org In-Reply-To: <20020208033304.83373.qmail@web20805.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org At 07:33 PM 2/7/2002, senthil ayyasamy wrote: >It seems to me that implementing IEPS >requires remodeling many protocols at various levels >in the TCP/IP stack . The very simple case of >modifying the DS codepoint (to include priority) will >require changes in many TCP/IP protocols. doesn't that sort of presume that we're putting priority back into the DS code point, having just shown (through 20 years experience) that combining the policy with the label is the wrong approach? I think you will need some very clear evidence that there is a problem with data traffic that is not addressed by current things before we'll be prepared to do that. The discussion of call priority has to do with call signalling, not data content. That's not a DSCP, it's a SIP/H.248/whatever information element of some sort. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Feb 14 16:31:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10310 for ; Thu, 14 Feb 2002 16:31:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28292; Thu, 14 Feb 2002 16:31:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28256 for ; Thu, 14 Feb 2002 16:31:03 -0500 (EST) Received: from dnsmx1pya.telcordia.com (dnsmx1pya.telcordia.com [128.96.20.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10294 for ; Thu, 14 Feb 2002 16:30:56 -0500 (EST) From: nabbott@TELCORDIA.COM Received: from notes900.cc.telcordia.com (notes900.cc.telcordia.com [128.96.79.7]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with ESMTP id QAA08479; Thu, 14 Feb 2002 16:23:53 -0500 (EST) To: Fred Baker Cc: "ieprep List (E-mail)" , "Folts, Harold" , "Nathan Wilcox (E-mail)" , "Tom Hinkelman (E-mail)" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Thu, 14 Feb 2002 16:23:55 -0500 X-MIMETrack: Serialize by Router on notes900/Telcordia(Release 5.0.6a |January 17, 2001) at 02/14/2002 04:23:56 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Ieprep] Re: Proposed IETF Working Group - ieprep Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org Mr. Baker, I wanted to make you aware of the National Emergency Number Association (NENA), an association of Public Safety organizations, government regulatory bodies, network providers and equipment providers, whose mission is to foster the technological advancement, availability, and implementation of a universal emergency telephone number system. In carrying out its mission, NENA promotes research, planning, training and education. NENA's expertise touches on all areas of providing emergency services, including architectures, and standards for data bases and signaling. (Refer to www.nena.org.) NENA's Emerging Technologies subcommittee and Migration working group are actively in the process of addressing some of the concerns in your charter: i.e., identifying "gaps" in VoP support for emergency services, as well as new desired functionality. I have passed your notice on to this group. Please consider NENA's input as a vital part of your committees work. There is a wealth of experience available in NENA, and keeping channels open will help avoid needless false starts. Thanks, Nadine Abbott Fred Baker om> cc: "ieprep List (E-mail)" , "IEPS List (E-mail)" 02/09/2002 , Scott Bradner 03:40 PM , (bcc: Nadine B. Please Abbott/Telcordia) respond to Subject: Re: Proposed IETF Working Group - Fred Baker ieprep At 12:40 AM 2/8/2002, Folts, Harold wrote: >A BOF for ieprep is on the agenda for IETF 53 in Minneapolis next month >3:30-5:30 pm. We expect to discuss the charter, further discuss the issues, >and plan a path ahead. that is in fact incorrect. A working group has been chartered, and you posted the announcement of its charter. I am the chair, and there will be a co-chair when the IESG appoints one. What will be meeting at that time is the first meeting of the working group. The charter of the working group is limited, and the plan is to complete a its tasks fairly quickly - by the end of summer. If as a result of that it is clear that additional work is required, the IESG will revise the charter. The charter of the working group might be summarized in this way: - we need a gap analysis between the PSTN and the various protocols used in VoIP, so that we can determine what differences may be relevant in an emergency situation. - where the gap analysis shows deficiencies (and we already know that deficiencies exist, such as the lack of an information element identifying an emergency call), our responsibility is to document them. Resolving them is the responsibility of the relevant WG. - In addition, various services have been proposed using the data capabilities of the network. We need to perform a gap analysis to ensure that the data network in fact adequately supports those applications. - ultimately, we need to provide some advice to those who might contract or deploy e911-style services, so that design expectations are set all around. I am putting together an agenda for the first meeting now, and would like folks who want agenda time to address these issues to contact me privately. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Feb 14 16:58:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10982 for ; Thu, 14 Feb 2002 16:58:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29419; Thu, 14 Feb 2002 16:57:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29387 for ; Thu, 14 Feb 2002 16:57:43 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10976 for ; Thu, 14 Feb 2002 16:57:38 -0500 (EST) Received: from FRED-W2K6.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1ELv6E21193; Thu, 14 Feb 2002 13:57:06 -0800 (PST) Message-Id: <4.3.2.7.2.20020214135524.01ee39e8@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 14 Feb 2002 13:56:53 -0800 To: nabbott@TELCORDIA.COM From: Fred Baker Subject: Re: [Ieprep] Re: Proposed IETF Working Group - ieprep Cc: "ieprep List (E-mail)" , "Folts, Harold" , "Nathan Wilcox (E-mail)" , "Tom Hinkelman (E-mail)" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org Thanks. Your IETF involvement will no doubt be useful. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Feb 14 17:40:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11854 for ; Thu, 14 Feb 2002 17:40:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01431; Thu, 14 Feb 2002 17:39:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01394 for ; Thu, 14 Feb 2002 17:39:47 -0500 (EST) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11832 for ; Thu, 14 Feb 2002 17:39:44 -0500 (EST) Received: from JMPOLK-W2K (ssh-sj1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id OAA26971; Thu, 14 Feb 2002 14:39:15 -0800 (PST) Message-Id: <4.1.20020214162330.02f4cc20@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 14 Feb 2002 16:38:52 -0600 To: ieprep@ietf.org From: "James M. Polk" Subject: Re: [Ieprep] implementation issues Cc: hgs@opus.cs.columbia.edu In-Reply-To: <4.3.2.7.2.20020210123613.022e5298@mira-sjcm-2.cisco.com> References: <20020208033304.83373.qmail@web20805.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_66981704==_.ALT" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org --=====================_66981704==_.ALT Content-Type: text/plain; charset="us-ascii" At 12:40 PM 2/10/2002 -0800, Fred Baker wrote: >At 07:33 PM 2/7/2002, senthil ayyasamy wrote: >>It seems to me that implementing IEPS >>requires remodeling many protocols at various levels >>in the TCP/IP stack . The very simple case of >>modifying the DS codepoint (to include priority) will >>require changes in many TCP/IP protocols. > >doesn't that sort of presume that we're putting priority back into the DS >code point, having just shown (through 20 years experience) that combining >the policy with the label is the wrong approach? I think you will need some >very clear evidence that there is a problem with data traffic that is not >addressed by current things before we'll be prepared to do that. > >The discussion of call priority has to do with call signalling, not data >content. That's not a DSCP, it's a SIP/H.248/whatever information element >of some sort. The extension for SIP called the 'Resource Priority Header' was proposed in SLC (Dec 01), and was mentioned during the IEPREP BOF as having signaling text specific for ETS (IEPS) and other Priority services capabilities http://www.ietf.org/internet-drafts/draft-polk-sip-resource-01.txt is about to go to -02 if there is a problem with accessing this version > > >_______________________________________________ >Ieprep mailing list >Ieprep@ietf.org >https://www1.ietf.org/mailman/listinfo/ieprep ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_66981704==_.ALT Content-Type: text/html; charset="us-ascii"
At 12:40 PM 2/10/2002 -0800, Fred Baker wrote:
>At 07:33 PM 2/7/2002, senthil ayyasamy wrote:
>>It seems to me that implementing IEPS
>>requires remodeling many protocols at various levels
>>in the TCP/IP stack . The very simple case of
>>modifying the DS codepoint (to include priority) will
>>require changes in many TCP/IP protocols.
>
>doesn't that sort of presume that we're putting priority back into the DS
>code point, having just shown (through 20 years experience) that combining
>the policy with the label is the wrong approach? I think you will need some
>very clear evidence that there is a problem with data traffic that is not
>addressed by current things before we'll be prepared to do that.
>
>The discussion of call priority has to do with call signalling, not data
>content. That's not a DSCP, it's a SIP/H.248/whatever information element
>of some sort.

The extension for SIP called the 'Resource Priority Header' was proposed in SLC (Dec 01), and was mentioned during the IEPREP BOF as having signaling text specific for ETS (IEPS) and other Priority services capabilities
is about to go to -02 if there is a problem with accessing this version

>
>
>_______________________________________________
>Ieprep mailing list
>Ieprep@ietf.org

*************************************
"People generally demand more respect for their own rights than they are willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_66981704==_.ALT-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sat Feb 23 01:01:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08482 for ; Sat, 23 Feb 2002 01:01:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA19545; Sat, 23 Feb 2002 01:01:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA19513 for ; Sat, 23 Feb 2002 01:01:12 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08478 for ; Sat, 23 Feb 2002 01:01:08 -0500 (EST) Received: from FRED-W2K6.cisco.com ([171.71.21.235]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1N60dw01277 for ; Fri, 22 Feb 2002 22:00:39 -0800 (PST) Message-Id: <4.3.2.7.2.20020222210914.02117b10@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Feb 2002 21:09:42 -0800 To: ieprep@ietf.org From: Fred Baker Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ieprep] Fwd: WG ACTION: Internet Emergency Preparedness (ieprep) Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org >From: The IESG >To: IETF-Announce: ; >Subject: WG ACTION: Internet Emergency Preparedness (ieprep) >Date: Fri, 22 Feb 2002 18:48:21 -0500 >Sender: scoya@cnri.reston.va.us > > >A new working group has been formed in the Transport Area of the IETF. >For additional information, contact the Area Directors >or the WG Chair. > > >Internet Emergency Preparedness (ieprep) >---------------------------------------- > > Charter > > Current Status: Active Working Group > > Chair(s): > Fred Baker > > Transport Area Director(s): > Scott Bradner > Allison Mankin > > Transport Area Advisor: > Scott Bradner > > Mailing Lists: > General Discussion:ieprep@ietf.org > To Subscribe: ieprep-request@ietf.org > In Body: subscribe ieprep > Archive: ftp://ftp.ietf.org/ietf-mail-archive/ieprep/ > >Description of Working Group: > >Effective telecommunications capabilities are imperative to facilitate >immediate recovery operations for serious disaster events, such as, >hurricanes, floods, earthquakes, and terrorist attacks. 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. > >Three examples of emergency communications include: > >1. Conveying information about the priority of specific phone calls > that originate in a VoIP environment through gateways to the PSTN. > >2. Access and transport for database and information distribution > applications relevant to managing the crisis. One example of this > is the I am Alive (IAA) system that can be used by people in a > disaster zone to register the fact that they are alive so that > their friends and family can check on their health. > >3. Interpersonal communication among crisis management personnel using > electronic mail and instant messaging. > >Initial documents will describe the problem space and its salient >characteristics. In particular the working group will devlop a >Requirements for Internet Emergency Preparedness in the Internet RFC >which will detail the specific functions and technologies needed to >provide support for Emergency Preparedness systems in the Internet. The >working group may also develop a Framework for Supporting Internet >Emergency Preparedness in IP Telephony RFC if it is determined that IP >telephony requires special treatment above what would be in the >requirements document. > >The international community needs advice as to what standards to rely >on, in the form of a BCP. This BCP needs to identify mechanisms to >provide deterministic behavior of applications, mechanisms for >authentication and authorization, and recommendations for application >design with existing protocols. 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, Differentiated Services, Protocol >for carrying Authentication for Network Access (pana), and various >operational groups, so the IEPREP working group will have to cooperate >closely with these groups and with groups outside of the IETF such as >various ITU-T study groups. > >The working group will develop a BCP RFC or set of RFCs, regarding >operational implementation of services for Emergency Preparedness using >existing Internet protocols. The RFC may include identification of gaps >in existing protocols and requirements for use in new protocol or >protocol feature design. It is out of scope for this working group to >do protocol or protocol feature development. The working group will >not focus on particular national regulations. > >Deliverables > >Best Current Practice: > IETF Recommendations for the Emergency Telecommunications Service > using existing protocols - what can be done with existing protcols > and what can not be done. > >Informationals: > Requirements for Internet Emergency Preparedness in the Internet. > Framework for Supporting Internet Emergency Preparedness in IP > Telephony. > > Goals and Milestones: > > Mar 02 Submit initial I-D of > Requirements > > Mar 02 Submit initial I-D of > Framework > > Mar 02 Submit initial I-D of Recommendations > BCP > > Aug 02 Submit Requirements I-D to IESG for publication as an > Informational > RFC. > > Aug 02 Submit Framework I-D to IESG for publication as an > Informational > RFC. > > Aug 02 Submit Recommendations I-D to IESG for publication as a > BCP. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Feb 26 03:42:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20744 for ; Tue, 26 Feb 2002 03:42:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA27182; Tue, 26 Feb 2002 03:40:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA27132 for ; Tue, 26 Feb 2002 03:40:09 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20706 for ; Tue, 26 Feb 2002 03:40:05 -0500 (EST) Received: from FRED-W2K6.cisco.com ([171.71.21.235]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1Q8dbw12305; Tue, 26 Feb 2002 00:39:37 -0800 (PST) Message-Id: <4.3.2.7.2.20020225235131.0233a7e0@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 25 Feb 2002 23:59:12 -0800 To: ieprep@ietf.org From: Fred Baker Cc: sob@sobco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ieprep] liaison from ITU-T SG16 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org You may find a liaison from SG 16 at ftp://ftpeng.cisco.com/fred/ieprep/ls36-16.pdf. I propose to send them the URL of our charter (which they are already in receipt of via the new-work list); it in turn contains pointers to existing individual submissions. That URL is http://www.ietf.org/html.charters/ieprep-charter.html. Working group comment is solicited; if you think there is something more I need to say, I'm listening... _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Feb 27 19:11:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25237 for ; Wed, 27 Feb 2002 19:11:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10410; Wed, 27 Feb 2002 19:10:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08543 for ; Tue, 26 Feb 2002 07:04:51 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24591; Tue, 26 Feb 2002 07:04:48 -0500 (EST) Message-Id: <200202261204.HAA24591@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ieprep@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 26 Feb 2002 07:04:48 -0500 Subject: [Ieprep] I-D ACTION:draft-brown-ieprep-sec-00.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Emergency Preparedness Working Group of the IETF. Title : Securing prioritised emergency traffic Author(s) : I. Brown Filename : draft-brown-ieprep-sec-00.txt Pages : 12 Date : 25-Feb-02 The International Emergency Preference Scheme and International Emergency Multimedia Service are ITU recommendations that give priority to emergency communications related to disaster recovery. This memo describes the security requirements of providing equivalent functionality in private and public IP networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brown-ieprep-sec-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-brown-ieprep-sec-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-brown-ieprep-sec-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020225143147.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-brown-ieprep-sec-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-brown-ieprep-sec-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020225143147.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Feb 27 19:11:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25240 for ; Wed, 27 Feb 2002 19:11:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10359; Wed, 27 Feb 2002 19:10:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08515 for ; Tue, 26 Feb 2002 07:04:43 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24565; Tue, 26 Feb 2002 07:04:40 -0500 (EST) Message-Id: <200202261204.HAA24565@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ieprep@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 26 Feb 2002 07:04:40 -0500 Subject: [Ieprep] I-D ACTION:draft-baker-ieprep-requirements-00.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Emergency Preparedness Working Group of the IETF. Title : IEPS Requirement Statement Author(s) : F. Baker Filename : draft-baker-ieprep-requirements-00.txt Pages : 19 Date : 25-Feb-02 The requirements for an Internet Emergency Preference Scheme comparable to the US Government Emergency Telecommunications Service are explored. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-baker-ieprep-requirements-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-baker-ieprep-requirements-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-baker-ieprep-requirements-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020225143135.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-baker-ieprep-requirements-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-baker-ieprep-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020225143135.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Feb 27 19:11:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25262 for ; Wed, 27 Feb 2002 19:11:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10319; Wed, 27 Feb 2002 19:10:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08490 for ; Tue, 26 Feb 2002 07:04:38 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24540; Tue, 26 Feb 2002 07:04:35 -0500 (EST) Message-Id: <200202261204.HAA24540@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ieprep@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 26 Feb 2002 07:04:35 -0500 Subject: [Ieprep] I-D ACTION:draft-carlberg-ieprep-framework-00.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Emergency Preparedness Working Group of the IETF. Title : Framework for Supporting IEPS in IP Telephony Author(s) : K. Carlberg, I. Brown Filename : draft-carlberg-ieprep-framework-00.txt Pages : 24 Date : 25-Feb-02 This document presents a framework for supporting authorized emergency related communication within the context of IP telephony. We present a series of objectives that reflect a general view of how authorized emergency service, in line with the International Emergency Preparedness Scheme (IEPS), should be realized within today's IP architecture and service models. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-carlberg-ieprep-framework-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-carlberg-ieprep-framework-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-carlberg-ieprep-framework-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020225143121.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-carlberg-ieprep-framework-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-carlberg-ieprep-framework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020225143121.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Feb 27 19:11:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25279 for ; Wed, 27 Feb 2002 19:11:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10275; Wed, 27 Feb 2002 19:10:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08465 for ; Tue, 26 Feb 2002 07:04:33 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24509; Tue, 26 Feb 2002 07:04:30 -0500 (EST) Message-Id: <200202261204.HAA24509@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ieprep@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 26 Feb 2002 07:04:29 -0500 Subject: [Ieprep] I-D ACTION:draft-folts-ieprep-white-paper-00.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Emergency Preparedness Working Group of the IETF. Title : Emergency Telecommunications Service in Evolving Networks Author(s) : H. Folts Filename : draft-folts-ieprep-white-paper-00.txt Pages : 13 Date : 25-Feb-02 This white paper presents the functional requirements, features, and objectives for the Emergency Telecommunications Service (ETS) in newly emerging telecommunication networks. The ETS is an extension of the International Emergency Preference Scheme (IEPS) of the ITU-T Recommendation E.106 [1] and includes additional provisions for multimedia services through an packet-based telecommunications environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-folts-ieprep-white-paper-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-folts-ieprep-white-paper-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-folts-ieprep-white-paper-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020225143107.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-folts-ieprep-white-paper-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-folts-ieprep-white-paper-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020225143107.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep