From mailman-bounces@ietf.org Fri Oct 1 10:23:26 2004 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 KAA04232 for ; Fri, 1 Oct 2004 10:23:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDOSD-0008Iq-GY for sipping-emergency-web-archive@ietf.org; Fri, 01 Oct 2004 10:32:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDKEa-0008Jb-F8 for sipping-emergency-web-archive@ietf.org; Fri, 01 Oct 2004 06:01:52 -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: sipping-emergency-web-archive@ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Oct 2004 05:23:48 -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 sipping-emergency-web-archive@ietf.org: List Password // URL ---- -------- sipping-emergency@ietf.org imavoz https://www1.ietf.org/mailman/options/sipping-emergency/sipping-emergency-web-archive%40ietf.org From sipping-emergency-bounces@ietf.org Mon Oct 4 15:40:21 2004 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 PAA07923 for ; Mon, 4 Oct 2004 15:40:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEYq4-0002Ko-Ea for sipping-emergency-web-archive@ietf.org; Mon, 04 Oct 2004 15:49:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEYNH-0003lM-Ge; Mon, 04 Oct 2004 15:19:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEYIw-0001M1-PM for sipping-emergency@megatron.ietf.org; Mon, 04 Oct 2004 15:15:26 -0400 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 PAA05110 for ; Mon, 4 Oct 2004 15:15:24 -0400 (EDT) Message-Id: <200410041915.PAA05110@ietf.org> Received: from winwebhosting.com ([67.15.20.8] helo=dx24.winwebhosting.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEYRv-00075h-71 for sipping-emergency@ietf.org; Mon, 04 Oct 2004 15:24:53 -0400 Received: from acs-24-154-127-195.zoominternet.net ([24.154.127.195] helo=BROSENLT) by dx24.winwebhosting.com with esmtpa (Exim 4.42) id 1CEYIg-00038V-Qr; Mon, 04 Oct 2004 14:15:11 -0500 From: "Brian Rosen" To: "'Jon Peterson'" Date: Mon, 4 Oct 2004 15:15:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcSqRnQv0eCFBQczTLufugiznib8PQ== X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx24.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: sipping-emergency@ietf.org Subject: [Sipping-emergency] Status of Proposed Charter X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Jon There was a flurry of email, but it seems to have died down. I sent an email with some specific suggestions to modify the proposed charter early in the exchange. Where do you think we are? Is there going to be a BOF in Washington? Brian _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Mon Oct 11 02:03:36 2004 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 CAA22431 for ; Mon, 11 Oct 2004 02:03:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGtRz-00086x-Ei for sipping-emergency-web-archive@ietf.org; Mon, 11 Oct 2004 02:14:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGtG0-0007oF-GY; Mon, 11 Oct 2004 02:02:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGtFO-0007Tc-Ck for sipping-emergency@megatron.ietf.org; Mon, 11 Oct 2004 02:01:26 -0400 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 CAA20040 for ; Mon, 11 Oct 2004 02:01:25 -0400 (EDT) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGtPr-00084m-Lm for sipping-emergency@ietf.org; Mon, 11 Oct 2004 02:12:15 -0400 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id i9B60sPm010547 for ; Mon, 11 Oct 2004 06:00:55 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Mon, 11 Oct 2004 02:00:54 -0400 Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF423D@stntexch04.cis.neustar.com> From: "Peterson, Jon" To: sipping-emergency@ietf.org Date: Mon, 11 Oct 2004 02:00:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.8 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Subject: [Sipping-emergency] New revision of proposed ECRIT charter X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e All, Here's a new version of the ECRIT charter for your consideration, that attempts to incorporate the discussion over the past couple of weeks. Any further issues? Jon Peterson NeuStar, Inc. --- Emergency Context Resolution with Internet Technologies (ECRIT) Transport Area Director(s): Allison Mankin Jon Peterson Transport Area Advisor: TBD Working Group Chairs: TBD In a number of areas the public switched telephone network (PSTN) has been configured to recognize an explicitly specified number (commonly one that is short and easily memorized) as a call for emergency services. These numbers (e.g. 911, 112) relate to an emergency service context and depend on a broad, regional configuration of service contact methods and a geographically constrained context of service delivery. These calls are intended to be delivered to special call centers equipped to manage emergency response. Successful delivery of an emergency service call within those systems requires both an association of the physical location of the originator with an appropriate emergency service center and call routing to deliver the call to the center. Calls placed using Internet technologies do not use the same systems to achieve those goals, and the common use of overlay networks and tunnels (either as VPNs or for mobility) makes meeting them more challenging. There are, however, Internet technologies available to describe location and to manage call routing. This working group will describe when these may be appropriate and how they may be used. Explicitly outside the scope of this group is the question of pre-emption or prioritization of emergency services traffic. This group is considering emergency services calls which might be made by any user of the PSTN or Internet, as opposed to government or military services that may impose very different authentication and routing requirements. The group will show how the availability of location data and call routing information at different steps in session setup would enable communication between a user and a relevant emergency response center. Though the term "call routing" is used in this document, it should be understood that some of the mechanisms which will be described might be used to enable other types of media streams. Video and text messaging, for example, might be used to request emergency services. While this group anticipates a close working relationship with NENA, any solution presented must be useful regardless of jurisdiction, and it must be possible to use without a single, central authority. Further, it must be possible for multiple delegations within a jurisdiction to be handled independently, as call routing for specific emergency types may be indepdent. Deliverables: Informational RFC containing terminology definitions and the requirements. A BCP describing how to identify a session set-up request is to an emergency response center. A BCP describing strategies for associating session originators with physical locations. A BCP or Standards Track RFC describing how to route an emergency call based on location information. Either within that document or as a separate document, a description of how error conditions are returned to the session originator and how to test for error conditions without activating an emergency response. Privacy concerns related to that testing must be addressed in this document set. A BCP describing how to discover the media stream types an ERC supports. An Informational document describing the threats and security considerations. _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Mon Oct 11 09:05:13 2004 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 JAA04117 for ; Mon, 11 Oct 2004 09:05:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH024-0007bJ-4H for sipping-emergency-web-archive@ietf.org; Mon, 11 Oct 2004 09:16:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGzmS-0005Ej-MJ; Mon, 11 Oct 2004 09:00:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGzjv-0004f4-5r for sipping-emergency@megatron.ietf.org; Mon, 11 Oct 2004 08:57:23 -0400 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 IAA03579 for ; Mon, 11 Oct 2004 08:57:21 -0400 (EDT) Message-Id: <200410111257.IAA03579@ietf.org> Received: from winwebhosting.com ([67.15.20.8] helo=dx24.winwebhosting.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGzuI-0007SO-KT for sipping-emergency@ietf.org; Mon, 11 Oct 2004 09:08:17 -0400 Received: from acs-24-154-127-195.zoominternet.net ([24.154.127.195] helo=BROSENLT) by dx24.winwebhosting.com with esmtpa (Exim 4.42) id 1CGzjf-0002Iv-OY; Mon, 11 Oct 2004 07:57:07 -0500 From: "Brian Rosen" To: "'Peterson, Jon'" , Subject: RE: [Sipping-emergency] New revision of proposed ECRIT charter Date: Mon, 11 Oct 2004 08:57:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcSvWAihsfaHSJ2eSeGAtvmsUajiZQAOJvUw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <7927C67249E4AD43BC05B539AF0D129801AF423D@stntexch04.cis.neustar.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx24.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.8 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: 7bit X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 1.5 (+) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: 7bit Looks pretty good. You might expand "NENA" to include other international agencies. ETSI EMTEL might be an example. I take it that the language "Either within that document or as a > separate > document, a description of how error conditions are returned to the > session > originator was intended to cover the "validation" concern. This language is not sufficient, because validation most often occurs before a session is originated. Would you consider changing the latter part to: "a description of how errors are returned"? Will there be a BOF for ECRIT in Washington? Brian > -----Original Message----- > From: sipping-emergency-bounces@ietf.org [mailto:sipping-emergency- > bounces@ietf.org] On Behalf Of Peterson, Jon > Sent: Monday, October 11, 2004 2:01 AM > To: sipping-emergency@ietf.org > Subject: [Sipping-emergency] New revision of proposed ECRIT charter > > > All, > > Here's a new version of the ECRIT charter for your consideration, that > attempts to incorporate the discussion over the past couple of weeks. > > Any further issues? > > Jon Peterson > NeuStar, Inc. > > --- > > Emergency Context Resolution with Internet Technologies (ECRIT) > > Transport Area Director(s): > Allison Mankin > Jon Peterson > > Transport Area Advisor: TBD > > Working Group Chairs: TBD > > In a number of areas the public switched telephone network (PSTN) > has been configured to recognize an explicitly specified number (commonly > one that is short and easily memorized) as a call for emergency services. > These numbers (e.g. 911, 112) relate to an emergency service context and > depend > on a broad, regional configuration of service contact methods and a > geographically > constrained context of service delivery. These calls are intended to be > delivered to > special call centers equipped to manage emergency response. Successful > delivery > of an emergency service call within those systems requires both an > association of > the physical location of the originator with an appropriate emergency > service > center and call routing to deliver the call to the center. > > Calls placed using Internet technologies do not use the same systems to > achieve those goals, and the common use of overlay networks and tunnels > (either as VPNs or for mobility) makes meeting them more challenging. > There > are, however, Internet technologies available to describe location and to > manage call routing. This working group will describe when these may be > appropriate > and how they may be used. Explicitly outside the scope of this group > is the question of pre-emption or prioritization of emergency services > traffic. This group is considering emergency services calls which might be > made by > any user of the PSTN or Internet, as opposed to government or military > services that may impose very different authentication and routing > requirements. > > The group will show how the availability of location data and call routing > information > at different steps in session setup would enable communication between a > user > and a relevant emergency response center. Though the term "call routing" > is > used in this > document, it should be understood that some of the mechanisms which > will be described might be used to enable other types of media > streams. Video and text messaging, for example, might be used to request > emergency services. > > While this group anticipates a close working relationship with NENA, any > solution > presented must be useful regardless of jurisdiction, and it must be > possible > to > use without a single, central authority. Further, it must be possible for > multiple > delegations within a jurisdiction to be handled independently, as call > routing > for specific emergency types may be indepdent. > > Deliverables: > > Informational RFC containing terminology definitions and the requirements. > > A BCP describing how to identify a session set-up request is to an > emergency > response center. > > A BCP describing strategies for associating session originators with > physical locations. > > A BCP or Standards Track RFC describing how to route an emergency call > based on location information. Either within that document or as a > separate > document, a description of how error conditions are returned to the > session > originator and how to test for error conditions without activating an > emergency > response. Privacy concerns related to that testing must be addressed > in this document set. > > A BCP describing how to discover the media stream types an ERC supports. > > An Informational document describing the threats and security > considerations. > > > _______________________________________________ > Sipping-emergency mailing list > Sipping-emergency@ietf.org > https://www1.ietf.org/mailman/listinfo/sipping-emergency > _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Mon Oct 11 09:29:08 2004 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 JAA05515 for ; Mon, 11 Oct 2004 09:29:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH0PD-0007zc-IQ for sipping-emergency-web-archive@ietf.org; Mon, 11 Oct 2004 09:40:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH0CZ-000159-2L; Mon, 11 Oct 2004 09:26:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH0CO-0000y5-Gj for sipping-emergency@megatron.ietf.org; Mon, 11 Oct 2004 09:26:48 -0400 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 JAA05397 for ; Mon, 11 Oct 2004 09:26:46 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH0Mv-0007w6-Mj for sipping-emergency@ietf.org; Mon, 11 Oct 2004 09:37:42 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 11 Oct 2004 06:34:50 -0700 X-BrightmailFiltered: true Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i9BDQDOE001429; Mon, 11 Oct 2004 06:26:13 -0700 (PDT) Received: from mlinsnerzk7abh (ssh-sjc-1.cisco.com [171.68.225.134]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA04815; Mon, 11 Oct 2004 06:26:12 -0700 (PDT) From: "Marc Linsner" To: "'Peterson, Jon'" , Subject: RE: [Sipping-emergency] New revision of proposed ECRIT charter Date: Mon, 11 Oct 2004 09:26:13 -0400 Message-ID: <000201c4af95$e208ec40$2c0d0d0a@mlinsnerzk7abh> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <7927C67249E4AD43BC05B539AF0D129801AF423D@stntexch04.cis.neustar.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Spam-Score: 1.9 (+) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7bit X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 1.9 (+) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: 7bit I like it.....I agree with Brian, we need to include EMTEL. -Marc Linsner- > -----Original Message----- > From: sipping-emergency-bounces@ietf.org > [mailto:sipping-emergency-bounces@ietf.org] On Behalf Of Peterson, Jon > Sent: Monday, October 11, 2004 2:01 AM > To: sipping-emergency@ietf.org > Subject: [Sipping-emergency] New revision of proposed ECRIT charter > > > > All, > > Here's a new version of the ECRIT charter for your > consideration, that attempts to incorporate the discussion > over the past couple of weeks. > > Any further issues? > > Jon Peterson > NeuStar, Inc. > > --- > > Emergency Context Resolution with Internet Technologies (ECRIT) > > Transport Area Director(s): > Allison Mankin > Jon Peterson > > Transport Area Advisor: TBD > > Working Group Chairs: TBD > > In a number of areas the public switched telephone network > (PSTN) has been configured to recognize an explicitly > specified number (commonly one that is short and easily > memorized) as a call for emergency services. > These numbers (e.g. 911, 112) relate to an emergency service > context and depend on a broad, regional configuration of > service contact methods and a geographically constrained > context of service delivery. These calls are intended to be > delivered to special call centers equipped to manage > emergency response. Successful delivery of an emergency > service call within those systems requires both an > association of the physical location of the originator with > an appropriate emergency service center and call routing to > deliver the call to the center. > > Calls placed using Internet technologies do not use the same > systems to achieve those goals, and the common use of overlay > networks and tunnels (either as VPNs or for mobility) makes > meeting them more challenging. There are, however, Internet > technologies available to describe location and to manage > call routing. This working group will describe when these > may be appropriate > and how they may be used. Explicitly outside the scope of this group > is the question of pre-emption or prioritization of emergency > services traffic. This group is considering emergency > services calls which might be made by any user of the PSTN or > Internet, as opposed to government or military services that > may impose very different authentication and routing requirements. > > The group will show how the availability of location data and > call routing information at different steps in session setup > would enable communication between a user and a relevant > emergency response center. Though the term "call routing" is > used in this document, it should be understood that some of > the mechanisms which > will be described might be used to enable other types of media > streams. Video and text messaging, for example, might be used > to request emergency services. > > While this group anticipates a close working relationship > with NENA, any solution presented must be useful regardless > of jurisdiction, and it must be possible to use without a > single, central authority. Further, it must be possible for > multiple delegations within a jurisdiction to be handled > independently, as call routing for specific emergency types > may be indepdent. > > Deliverables: > > Informational RFC containing terminology definitions and the > requirements. > > A BCP describing how to identify a session set-up request is > to an emergency response center. > > A BCP describing strategies for associating session originators with > physical locations. > > A BCP or Standards Track RFC describing how to route an > emergency call based on location information. Either within > that document or as a separate document, a description of how > error conditions are returned to the session originator and > how to test for error conditions without activating an > emergency response. Privacy concerns related to that testing > must be addressed in this document set. > > A BCP describing how to discover the media stream types an > ERC supports. > > An Informational document describing the threats and security > considerations. > > > _______________________________________________ > Sipping-emergency mailing list > Sipping-emergency@ietf.org > https://www1.ietf.org/mailman/listinfo/sipping> -emergency > _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Mon Oct 11 13:59:20 2004 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 NAA27930 for ; Mon, 11 Oct 2004 13:59:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH4cj-0004zW-UG for sipping-emergency-web-archive@ietf.org; Mon, 11 Oct 2004 14:10:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH4LN-0001No-MS; Mon, 11 Oct 2004 13:52:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH4JV-0000xw-GO for sipping-emergency@megatron.ietf.org; Mon, 11 Oct 2004 13:50:25 -0400 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 NAA26990 for ; Mon, 11 Oct 2004 13:50:23 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH4U1-0004me-PE for sipping-emergency@ietf.org; Mon, 11 Oct 2004 14:01:21 -0400 Received: from [128.59.16.206] (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i9BHnbuu019375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Oct 2004 13:49:43 -0400 (EDT) Message-ID: <416AC7AC.5010304@cs.columbia.edu> Date: Mon, 11 Oct 2004 13:49:32 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" Subject: Re: [Sipping-emergency] New revision of proposed ECRIT charter References: <7927C67249E4AD43BC05B539AF0D129801AF423D@stntexch04.cis.neustar.com> In-Reply-To: <7927C67249E4AD43BC05B539AF0D129801AF423D@stntexch04.cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.10.10.0 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __PORN_PHRASE_15_0 0, __SANE_MSGID 0' X-Spam-Score: 0.8 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Cc: sipping-emergency@ietf.org X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Looks good to me, seconding the comments made by others. Peterson, Jon wrote: > All, > > Here's a new version of the ECRIT charter for your consideration, that > attempts to incorporate the discussion over the past couple of weeks. > > Any further issues? > > Jon Peterson > NeuStar, Inc. > > --- > > Emergency Context Resolution with Internet Technologies (ECRIT) > > Transport Area Director(s): > Allison Mankin > Jon Peterson > > Transport Area Advisor: TBD > > Working Group Chairs: TBD > > In a number of areas the public switched telephone network (PSTN) > has been configured to recognize an explicitly specified number (commonly > one that is short and easily memorized) as a call for emergency services. > These numbers (e.g. 911, 112) relate to an emergency service context and > depend > on a broad, regional configuration of service contact methods and a > geographically > constrained context of service delivery. These calls are intended to be > delivered to > special call centers equipped to manage emergency response. Successful > delivery > of an emergency service call within those systems requires both an > association of > the physical location of the originator with an appropriate emergency > service > center and call routing to deliver the call to the center. > > Calls placed using Internet technologies do not use the same systems to > achieve those goals, and the common use of overlay networks and tunnels > (either as VPNs or for mobility) makes meeting them more challenging. There > are, however, Internet technologies available to describe location and to > manage call routing. This working group will describe when these may be > appropriate > and how they may be used. Explicitly outside the scope of this group > is the question of pre-emption or prioritization of emergency services > traffic. This group is considering emergency services calls which might be > made by > any user of the PSTN or Internet, as opposed to government or military > services that may impose very different authentication and routing > requirements. > > The group will show how the availability of location data and call routing > information > at different steps in session setup would enable communication between a > user > and a relevant emergency response center. Though the term "call routing" is > used in this > document, it should be understood that some of the mechanisms which > will be described might be used to enable other types of media > streams. Video and text messaging, for example, might be used to request > emergency services. > > While this group anticipates a close working relationship with NENA, any > solution > presented must be useful regardless of jurisdiction, and it must be possible > to > use without a single, central authority. Further, it must be possible for > multiple > delegations within a jurisdiction to be handled independently, as call > routing > for specific emergency types may be indepdent. > > Deliverables: > > Informational RFC containing terminology definitions and the requirements. > > A BCP describing how to identify a session set-up request is to an emergency > response center. > > A BCP describing strategies for associating session originators with > physical locations. > > A BCP or Standards Track RFC describing how to route an emergency call > based on location information. Either within that document or as a separate > document, a description of how error conditions are returned to the session > originator and how to test for error conditions without activating an > emergency > response. Privacy concerns related to that testing must be addressed > in this document set. > > A BCP describing how to discover the media stream types an ERC supports. > > An Informational document describing the threats and security > considerations. > > > _______________________________________________ > Sipping-emergency mailing list > Sipping-emergency@ietf.org > https://www1.ietf.org/mailman/listinfo/sipping-emergency _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Mon Oct 11 14:44:20 2004 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 OAA02127 for ; Mon, 11 Oct 2004 14:44:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH5KI-00068b-J4 for sipping-emergency-web-archive@ietf.org; Mon, 11 Oct 2004 14:55:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH52D-0005AV-73; Mon, 11 Oct 2004 14:36:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH4wI-0003qv-TA for sipping-emergency@megatron.ietf.org; Mon, 11 Oct 2004 14:30:30 -0400 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 OAA00787 for ; Mon, 11 Oct 2004 14:30:29 -0400 (EDT) From: wilcox@e911.psd.state.vt.us Received: from [64.222.94.65] (helo=e911.psd.state.vt.us) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH56n-0005iR-Da for sipping-emergency@ietf.org; Mon, 11 Oct 2004 14:41:27 -0400 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping-emergency] New revision of proposed ECRIT charter X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 11 Oct 2004 14:30:55 -0400 Message-ID: Thread-Topic: [Sipping-emergency] New revision of proposed ECRIT charter thread-index: AcSvvHmaT9xA0UM3SWqoY0ErriZYLQAAwxLQ To: "Peterson, Jon" X-Spam-Score: 1.1 (+) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: quoted-printable Cc: sipping-emergency@ietf.org X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Content-Transfer-Encoding: quoted-printable I agree with all the comments so far.=20 Does the statement: "This group is considering emergency services calls = which might be made by any user of the PSTN or Internet" imply that, to = some degree, this group will also be considering how to route and/or = protocols for PSTN originated emergency calls for the ERC as well? Nate Peterson, Jon wrote: > All, >=20 > Here's a new version of the ECRIT charter for your consideration, that > attempts to incorporate the discussion over the past couple of weeks. >=20 > Any further issues? >=20 > Jon Peterson > NeuStar, Inc. >=20 > --- >=20 > Emergency Context Resolution with Internet Technologies (ECRIT) >=20 > Transport Area Director(s): > Allison Mankin > Jon Peterson >=20 > Transport Area Advisor: TBD >=20 > Working Group Chairs: TBD >=20 > In a number of areas the public switched telephone network (PSTN) > has been configured to recognize an explicitly specified number = (commonly > one that is short and easily memorized) as a call for emergency = services. =20 > These numbers (e.g. 911, 112) relate to an emergency service context = and > depend > on a broad, regional configuration of service contact methods and a > geographically > constrained context of service delivery. These calls are intended to = be > delivered to > special call centers equipped to manage emergency response. = Successful > delivery > of an emergency service call within those systems requires both an > association of > the physical location of the originator with an appropriate emergency > service > center and call routing to deliver the call to the center. >=20 > Calls placed using Internet technologies do not use the same systems = to > achieve those goals, and the common use of overlay networks and = tunnels > (either as VPNs or for mobility) makes meeting them more challenging. = There > are, however, Internet technologies available to describe location and = to > manage call routing. This working group will describe when these may = be > appropriate > and how they may be used. Explicitly outside the scope of this group > is the question of pre-emption or prioritization of emergency services > traffic. This group is considering emergency services calls which = might be > made by > any user of the PSTN or Internet, as opposed to government or military > services that may impose very different authentication and routing > requirements. >=20 > The group will show how the availability of location data and call = routing > information > at different steps in session setup would enable communication = between a > user > and a relevant emergency response center. Though the term "call = routing" is > used in this > document, it should be understood that some of the mechanisms which=20 > will be described might be used to enable other types of media=20 > streams. Video and text messaging, for example, might be used to = request > emergency services. >=20 > While this group anticipates a close working relationship with NENA, = any > solution > presented must be useful regardless of jurisdiction, and it must be = possible > to > use without a single, central authority. Further, it must be possible = for > multiple > delegations within a jurisdiction to be handled independently, as call > routing > for specific emergency types may be indepdent. >=20 > Deliverables: >=20 > Informational RFC containing terminology definitions and the = requirements. >=20 > A BCP describing how to identify a session set-up request is to an = emergency > response center. >=20 > A BCP describing strategies for associating session originators with=20 > physical locations. >=20 > A BCP or Standards Track RFC describing how to route an emergency call > based on location information. Either within that document or as a = separate > document, a description of how error conditions are returned to the = session > originator and how to test for error conditions without activating an > emergency > response. Privacy concerns related to that testing must be addressed > in this document set. >=20 > A BCP describing how to discover the media stream types an ERC = supports. >=20 > An Informational document describing the threats and security > considerations. >=20 >=20 > _______________________________________________ > Sipping-emergency mailing list > Sipping-emergency@ietf.org > https://www1.ietf.org/mailman/listinfo/sipping-emergency _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Mon Oct 11 17:32:12 2004 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 RAA00950 for ; Mon, 11 Oct 2004 17:32:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH7wm-0005gY-DQ for sipping-emergency-web-archive@ietf.org; Mon, 11 Oct 2004 17:43:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH7Zj-0003nk-FR; Mon, 11 Oct 2004 17:19:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH71l-0001Kd-0u for sipping-emergency@megatron.ietf.org; Mon, 11 Oct 2004 16:44:18 -0400 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 QAA22542 for ; Mon, 11 Oct 2004 16:44:14 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH7CM-0002wQ-Cn for sipping-emergency@ietf.org; Mon, 11 Oct 2004 16:55:14 -0400 Received: from dynamicsoft.com ([63.113.46.113]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i9BKi8pl016960; Mon, 11 Oct 2004 16:44:08 -0400 (EDT) Message-ID: <416AF07D.3020008@dynamicsoft.com> Date: Mon, 11 Oct 2004 16:43:41 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" Subject: Re: [Sipping-emergency] New revision of proposed ECRIT charter References: <7927C67249E4AD43BC05B539AF0D129801AF423D@stntexch04.cis.neustar.com> In-Reply-To: <7927C67249E4AD43BC05B539AF0D129801AF423D@stntexch04.cis.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: 7bit Cc: sipping-emergency@ietf.org X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: 7bit Sounds good to me. -Jonathan R. Peterson, Jon wrote: > All, > > Here's a new version of the ECRIT charter for your consideration, that > attempts to incorporate the discussion over the past couple of weeks. > > Any further issues? > > Jon Peterson > NeuStar, Inc. > > --- > > Emergency Context Resolution with Internet Technologies (ECRIT) > > Transport Area Director(s): > Allison Mankin > Jon Peterson > > Transport Area Advisor: TBD > > Working Group Chairs: TBD > > In a number of areas the public switched telephone network (PSTN) > has been configured to recognize an explicitly specified number (commonly > one that is short and easily memorized) as a call for emergency services. > These numbers (e.g. 911, 112) relate to an emergency service context and > depend > on a broad, regional configuration of service contact methods and a > geographically > constrained context of service delivery. These calls are intended to be > delivered to > special call centers equipped to manage emergency response. Successful > delivery > of an emergency service call within those systems requires both an > association of > the physical location of the originator with an appropriate emergency > service > center and call routing to deliver the call to the center. > > Calls placed using Internet technologies do not use the same systems to > achieve those goals, and the common use of overlay networks and tunnels > (either as VPNs or for mobility) makes meeting them more challenging. There > are, however, Internet technologies available to describe location and to > manage call routing. This working group will describe when these may be > appropriate > and how they may be used. Explicitly outside the scope of this group > is the question of pre-emption or prioritization of emergency services > traffic. This group is considering emergency services calls which might be > made by > any user of the PSTN or Internet, as opposed to government or military > services that may impose very different authentication and routing > requirements. > > The group will show how the availability of location data and call routing > information > at different steps in session setup would enable communication between a > user > and a relevant emergency response center. Though the term "call routing" is > used in this > document, it should be understood that some of the mechanisms which > will be described might be used to enable other types of media > streams. Video and text messaging, for example, might be used to request > emergency services. > > While this group anticipates a close working relationship with NENA, any > solution > presented must be useful regardless of jurisdiction, and it must be possible > to > use without a single, central authority. Further, it must be possible for > multiple > delegations within a jurisdiction to be handled independently, as call > routing > for specific emergency types may be indepdent. > > Deliverables: > > Informational RFC containing terminology definitions and the requirements. > > A BCP describing how to identify a session set-up request is to an emergency > response center. > > A BCP describing strategies for associating session originators with > physical locations. > > A BCP or Standards Track RFC describing how to route an emergency call > based on location information. Either within that document or as a separate > document, a description of how error conditions are returned to the session > originator and how to test for error conditions without activating an > emergency > response. Privacy concerns related to that testing must be addressed > in this document set. > > A BCP describing how to discover the media stream types an ERC supports. > > An Informational document describing the threats and security > considerations. > > > _______________________________________________ > Sipping-emergency mailing list > Sipping-emergency@ietf.org > https://www1.ietf.org/mailman/listinfo/sipping-emergency > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Wed Oct 13 18:25:31 2004 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 SAA20499 for ; Wed, 13 Oct 2004 18:25:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHrjs-0001ui-7h for sipping-emergency-web-archive@ietf.org; Wed, 13 Oct 2004 18:36:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHrMU-0006HS-DR; Wed, 13 Oct 2004 18: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 1CHr13-0001Dd-E5 for sipping-emergency@megatron.ietf.org; Wed, 13 Oct 2004 17:50:37 -0400 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 RAA14455 for ; Wed, 13 Oct 2004 17:50:36 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHrC4-0000LT-F0 for sipping-emergency@ietf.org; Wed, 13 Oct 2004 18:02:00 -0400 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9DLo1H18921; Wed, 13 Oct 2004 17:50:02 -0400 (EDT) Received: from [47.130.17.208] (acart551.ca.nortel.com [47.130.17.208]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SPNPMB95; Wed, 13 Oct 2004 17:50:02 -0400 Message-ID: <416DA308.7060302@nortelnetworks.com> Date: Wed, 13 Oct 2004 17:50:00 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" , sipping-emergency@ietf.org Subject: Re: [Sipping-emergency] New revision of proposed ECRIT charter References: <7927C67249E4AD43BC05B539AF0D129801AF423D@stntexch04.cis.neustar.com> In-Reply-To: <7927C67249E4AD43BC05B539AF0D129801AF423D@stntexch04.cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7bit X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: 7bit I forgot to say I'm happy with the charter as rewritten. I'll volunteer my services as chair or editor. Peterson, Jon wrote: > All, > > Here's a new version of the ECRIT charter for your consideration, that > attempts to incorporate the discussion over the past couple of weeks. > > Any further issues? > > Jon Peterson > NeuStar, Inc. > > --- > > Emergency Context Resolution with Internet Technologies (ECRIT) > > Transport Area Director(s): > Allison Mankin > Jon Peterson > > Transport Area Advisor: TBD > > Working Group Chairs: TBD > > In a number of areas the public switched telephone network (PSTN) > has been configured to recognize an explicitly specified number (commonly > one that is short and easily memorized) as a call for emergency services. > These numbers (e.g. 911, 112) relate to an emergency service context and > depend > on a broad, regional configuration of service contact methods and a > geographically > constrained context of service delivery. These calls are intended to be > delivered to > special call centers equipped to manage emergency response. Successful > delivery > of an emergency service call within those systems requires both an > association of > the physical location of the originator with an appropriate emergency > service > center and call routing to deliver the call to the center. > > Calls placed using Internet technologies do not use the same systems to > achieve those goals, and the common use of overlay networks and tunnels > (either as VPNs or for mobility) makes meeting them more challenging. There > are, however, Internet technologies available to describe location and to > manage call routing. This working group will describe when these may be > appropriate > and how they may be used. Explicitly outside the scope of this group > is the question of pre-emption or prioritization of emergency services > traffic. This group is considering emergency services calls which might be > made by > any user of the PSTN or Internet, as opposed to government or military > services that may impose very different authentication and routing > requirements. > > The group will show how the availability of location data and call routing > information > at different steps in session setup would enable communication between a > user > and a relevant emergency response center. Though the term "call routing" is > used in this > document, it should be understood that some of the mechanisms which > will be described might be used to enable other types of media > streams. Video and text messaging, for example, might be used to request > emergency services. > > While this group anticipates a close working relationship with NENA, any > solution > presented must be useful regardless of jurisdiction, and it must be possible > to > use without a single, central authority. Further, it must be possible for > multiple > delegations within a jurisdiction to be handled independently, as call > routing > for specific emergency types may be indepdent. > > Deliverables: > > Informational RFC containing terminology definitions and the requirements. > > A BCP describing how to identify a session set-up request is to an emergency > response center. > > A BCP describing strategies for associating session originators with > physical locations. > > A BCP or Standards Track RFC describing how to route an emergency call > based on location information. Either within that document or as a separate > document, a description of how error conditions are returned to the session > originator and how to test for error conditions without activating an > emergency > response. Privacy concerns related to that testing must be addressed > in this document set. > > A BCP describing how to discover the media stream types an ERC supports. > > An Informational document describing the threats and security > considerations. > > > _______________________________________________ > Sipping-emergency mailing list > Sipping-emergency@ietf.org > https://www1.ietf.org/mailman/listinfo/sipping-emergency > > -- Tom Taylor Carrier VoIP Standards Development Nortel Networks Phone +1 613 763 1496 (ESN 393-1496) E-mail: taylor@nortelnetworks.com _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Wed Oct 13 20:43:29 2004 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 UAA29203 for ; Wed, 13 Oct 2004 20:43:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHttL-0004R2-4n for sipping-emergency-web-archive@ietf.org; Wed, 13 Oct 2004 20:54:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHtUi-0003Zr-4F; Wed, 13 Oct 2004 20:29:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHtO2-0001pj-QZ for sipping-emergency@megatron.ietf.org; Wed, 13 Oct 2004 20:22:30 -0400 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 UAA28058 for ; Wed, 13 Oct 2004 20:22:31 -0400 (EDT) Received: from [206.173.41.176] (helo=sea-mailsweep-1.telecomsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHtZ4-00046m-Js for sipping-emergency@ietf.org; Wed, 13 Oct 2004 20:33:56 -0400 Received: from sea-exchange-1.xypoint.com (unverified [10.32.12.12]) by sea-mailsweep-1.telecomsys.com (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Wed, 13 Oct 2004 17:21:54 -0700 Received: by sea-exchange-1.telecomsys.com with Internet Mail Service (5.5.2656.59) id <4RC23PLN>; Wed, 13 Oct 2004 17:22:05 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A6575C8376E@SEA-EXCHVS-2.telecomsys.com> From: Roger Marshall To: "Peterson, Jon" , sipping-emergency@ietf.org Subject: RE: [Sipping-emergency] New revision of proposed ECRIT charter Date: Wed, 13 Oct 2004 17:21:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-Spam-Score: 0.8 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Jon: Does the mention of NENA imply a formal relationship of approval by either entity in any way, or rather an informal exchange of ideas and/or information between the two? Roger Marshall TeleCommunication Systems, Inc. -----Original Message----- From: sipping-emergency-bounces@ietf.org [mailto:sipping-emergency-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: Sunday, October 10, 2004 11:01 PM To: sipping-emergency@ietf.org Subject: [Sipping-emergency] New revision of proposed ECRIT charter All, Here's a new version of the ECRIT charter for your consideration, that attempts to incorporate the discussion over the past couple of weeks. Any further issues? Jon Peterson NeuStar, Inc. --- Emergency Context Resolution with Internet Technologies (ECRIT) Transport Area Director(s): Allison Mankin Jon Peterson Transport Area Advisor: TBD Working Group Chairs: TBD In a number of areas the public switched telephone network (PSTN) has been configured to recognize an explicitly specified number (commonly one that is short and easily memorized) as a call for emergency services. These numbers (e.g. 911, 112) relate to an emergency service context and depend on a broad, regional configuration of service contact methods and a geographically constrained context of service delivery. These calls are intended to be delivered to special call centers equipped to manage emergency response. Successful delivery of an emergency service call within those systems requires both an association of the physical location of the originator with an appropriate emergency service center and call routing to deliver the call to the center. Calls placed using Internet technologies do not use the same systems to achieve those goals, and the common use of overlay networks and tunnels (either as VPNs or for mobility) makes meeting them more challenging. There are, however, Internet technologies available to describe location and to manage call routing. This working group will describe when these may be appropriate and how they may be used. Explicitly outside the scope of this group is the question of pre-emption or prioritization of emergency services traffic. This group is considering emergency services calls which might be made by any user of the PSTN or Internet, as opposed to government or military services that may impose very different authentication and routing requirements. The group will show how the availability of location data and call routing information at different steps in session setup would enable communication between a user and a relevant emergency response center. Though the term "call routing" is used in this document, it should be understood that some of the mechanisms which will be described might be used to enable other types of media streams. Video and text messaging, for example, might be used to request emergency services. While this group anticipates a close working relationship with NENA, any solution presented must be useful regardless of jurisdiction, and it must be possible to use without a single, central authority. Further, it must be possible for multiple delegations within a jurisdiction to be handled independently, as call routing for specific emergency types may be indepdent. Deliverables: Informational RFC containing terminology definitions and the requirements. A BCP describing how to identify a session set-up request is to an emergency response center. A BCP describing strategies for associating session originators with physical locations. A BCP or Standards Track RFC describing how to route an emergency call based on location information. Either within that document or as a separate document, a description of how error conditions are returned to the session originator and how to test for error conditions without activating an emergency response. Privacy concerns related to that testing must be addressed in this document set. A BCP describing how to discover the media stream types an ERC supports. An Informational document describing the threats and security considerations. _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Fri Oct 15 13:25:30 2004 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 NAA22356 for ; Fri, 15 Oct 2004 13:25:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIW12-0004tC-WD for sipping-emergency-web-archive@ietf.org; Fri, 15 Oct 2004 13:37:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIVnW-0004wV-PL; Fri, 15 Oct 2004 13:23:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIVjg-0004QE-MO for sipping-emergency@megatron.ietf.org; Fri, 15 Oct 2004 13:19:25 -0400 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 NAA21896 for ; Fri, 15 Oct 2004 13:19:21 -0400 (EDT) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIVv5-0004kB-JQ for sipping-emergency@ietf.org; Fri, 15 Oct 2004 13:31:12 -0400 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id i9FHImPm027641; Fri, 15 Oct 2004 17:18:48 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Fri, 15 Oct 2004 13:18:48 -0400 Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF427F@stntexch04.cis.neustar.com> From: "Peterson, Jon" To: "'wilcox@e911.psd.state.vt.us'" Subject: RE: [Sipping-emergency] New revision of proposed ECRIT charter Date: Fri, 15 Oct 2004 13:18:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.8 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: sipping-emergency@ietf.org X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Well, it certainly isn't intended to imply that. Um... I suppose we can take out the term "PSTN" there. - J > -----Original Message----- > From: wilcox@e911.psd.state.vt.us [mailto:wilcox@e911.psd.state.vt.us] > Sent: Monday, October 11, 2004 11:31 AM > To: Peterson, Jon > Cc: sipping-emergency@ietf.org > Subject: RE: [Sipping-emergency] New revision of proposed > ECRIT charter > > > I agree with all the comments so far. > > Does the statement: "This group is considering emergency > services calls which might be made by any user of the PSTN or > Internet" imply that, to some degree, this group will also be > considering how to route and/or protocols for PSTN originated > emergency calls for the ERC as well? > > Nate > > Peterson, Jon wrote: > > All, > > > > Here's a new version of the ECRIT charter for your > consideration, that > > attempts to incorporate the discussion over the past couple > of weeks. > > > > Any further issues? > > > > Jon Peterson > > NeuStar, Inc. > > > > --- > > > > Emergency Context Resolution with Internet Technologies (ECRIT) > > > > Transport Area Director(s): > > Allison Mankin > > Jon Peterson > > > > Transport Area Advisor: TBD > > > > Working Group Chairs: TBD > > > > In a number of areas the public switched telephone network (PSTN) > > has been configured to recognize an explicitly specified > number (commonly > > one that is short and easily memorized) as a call for > emergency services. > > These numbers (e.g. 911, 112) relate to an emergency > service context and > > depend > > on a broad, regional configuration of service contact methods and a > > geographically > > constrained context of service delivery. These calls are > intended to be > > delivered to > > special call centers equipped to manage emergency > response. Successful > > delivery > > of an emergency service call within those systems requires both an > > association of > > the physical location of the originator with an > appropriate emergency > > service > > center and call routing to deliver the call to the center. > > > > Calls placed using Internet technologies do not use the > same systems to > > achieve those goals, and the common use of overlay networks > and tunnels > > (either as VPNs or for mobility) makes meeting them more > challenging. There > > are, however, Internet technologies available to describe > location and to > > manage call routing. This working group will describe when > these may be > > appropriate > > and how they may be used. Explicitly outside the scope of > this group > > is the question of pre-emption or prioritization of > emergency services > > traffic. This group is considering emergency services calls > which might be > > made by > > any user of the PSTN or Internet, as opposed to government > or military > > services that may impose very different authentication and routing > > requirements. > > > > The group will show how the availability of location data > and call routing > > information > > at different steps in session setup would enable > communication between a > > user > > and a relevant emergency response center. Though the term > "call routing" is > > used in this > > document, it should be understood that some of the mechanisms which > > will be described might be used to enable other types of media > > streams. Video and text messaging, for example, might be > used to request > > emergency services. > > > > While this group anticipates a close working relationship > with NENA, any > > solution > > presented must be useful regardless of jurisdiction, and it > must be possible > > to > > use without a single, central authority. Further, it must > be possible for > > multiple > > delegations within a jurisdiction to be handled > independently, as call > > routing > > for specific emergency types may be indepdent. > > > > Deliverables: > > > > Informational RFC containing terminology definitions and > the requirements. > > > > A BCP describing how to identify a session set-up request > is to an emergency > > response center. > > > > A BCP describing strategies for associating session > originators with > > physical locations. > > > > A BCP or Standards Track RFC describing how to route an > emergency call > > based on location information. Either within that document > or as a separate > > document, a description of how error conditions are > returned to the session > > originator and how to test for error conditions without > activating an > > emergency > > response. Privacy concerns related to that testing must be > addressed > > in this document set. > > > > A BCP describing how to discover the media stream types an > ERC supports. > > > > An Informational document describing the threats and security > > considerations. > > > > > > _______________________________________________ > > Sipping-emergency mailing list > > Sipping-emergency@ietf.org > > https://www1.ietf.org/mailman/listinfo/sipping-emergency > > _______________________________________________ > Sipping-emergency mailing list > Sipping-emergency@ietf.org > https://www1.ietf.org/mailman/listinfo/sipping-emergency > > _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Fri Oct 15 13:40:48 2004 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 NAA23599 for ; Fri, 15 Oct 2004 13:40:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIWFq-0005DK-RN for sipping-emergency-web-archive@ietf.org; Fri, 15 Oct 2004 13:52:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIVxf-0006WF-TY; Fri, 15 Oct 2004 13:33:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIVsq-0005na-LO for sipping-emergency@megatron.ietf.org; Fri, 15 Oct 2004 13:28:52 -0400 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 NAA22664 for ; Fri, 15 Oct 2004 13:28:49 -0400 (EDT) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIW4E-0004wb-UU for sipping-emergency@ietf.org; Fri, 15 Oct 2004 13:40:40 -0400 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id i9FHSKPm028005; Fri, 15 Oct 2004 17:28:20 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Fri, 15 Oct 2004 13:28:20 -0400 Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF4282@stntexch04.cis.neustar.com> From: "Peterson, Jon" To: sipping-emergency@ietf.org Date: Fri, 15 Oct 2004 13:28:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: "'Tschofenig Hannes'" Subject: [Sipping-emergency] agenda items for ecrit X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a First of all, thanks to everyone who volunteered to chair the BoF. Allison and I feel that for this initial meeting, it is probably more valuable for everyone on this list to be able to appear as a participant and a supporter of moving this effort forward. Accordingly, for the BoF, the chairs will be myself and Hannes Tschofenig. Obviously, if this effort does go forward into a working group, I at least won't be continuing as a chair. Also, this will make Allison the responsible AD for the BoF. Hannes and I are working on organizing an agenda request now. What we need most is some actual content, of course. Is anyone in this list interested in being a presenter, and if so, on what topics? We probably won't be asking for a lot of time, and Hannes and I will present the proposed charter itself, but it would be nice to have a small handful of focus presentations on the existing and/or planned work that the group would take on. Presentations should be focused on requirements/problem space rather than solutioning. Let us know. Jon Peterson NeuStar, Inc. _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Fri Oct 15 13:50:19 2004 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 NAA24189 for ; Fri, 15 Oct 2004 13:50:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIWP1-0005Of-GP for sipping-emergency-web-archive@ietf.org; Fri, 15 Oct 2004 14:02:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIWCz-0000cJ-9V; Fri, 15 Oct 2004 13:49:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIW9I-0008Vr-Sf for sipping-emergency@megatron.ietf.org; Fri, 15 Oct 2004 13:45:53 -0400 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 NAA23921 for ; Fri, 15 Oct 2004 13:45:51 -0400 (EDT) Message-Id: <200410151745.NAA23921@ietf.org> Received: from winwebhosting.com ([67.15.20.8] helo=dx24.winwebhosting.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIWKY-0005JH-4w for sipping-emergency@ietf.org; Fri, 15 Oct 2004 13:57:40 -0400 Received: from acs-24-154-127-195.zoominternet.net ([24.154.127.195] helo=BROSENLT) by dx24.winwebhosting.com with esmtpa (Exim 4.42) id 1CIW93-0003o1-Ed; Fri, 15 Oct 2004 12:45:37 -0500 From: "Brian Rosen" To: "'Peterson, Jon'" , Subject: RE: [Sipping-emergency] agenda items for ecrit Date: Fri, 15 Oct 2004 13:45:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcSy3hsUQN5rV/qwRkC0ZsRMRJsH+AAAHVyA In-Reply-To: <7927C67249E4AD43BC05B539AF0D129801AF4282@stntexch04.cis.neustar.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx24.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: "'Tschofenig Hannes'" X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit I would be willing to present on the problem space in North America and how they are handled now. Nate might be a better presenter for that but I don't think he can be there. Brian > -----Original Message----- > From: sipping-emergency-bounces@ietf.org [mailto:sipping-emergency- > bounces@ietf.org] On Behalf Of Peterson, Jon > Sent: Friday, October 15, 2004 1:28 PM > To: sipping-emergency@ietf.org > Cc: 'Tschofenig Hannes' > Subject: [Sipping-emergency] agenda items for ecrit > > > First of all, thanks to everyone who volunteered to chair the BoF. Allison > and I feel that for this initial meeting, it is probably more valuable for > everyone on this list to be able to appear as a participant and a > supporter > of moving this effort forward. > > Accordingly, for the BoF, the chairs will be myself and Hannes Tschofenig. > Obviously, if this effort does go forward into a working group, I at least > won't be continuing as a chair. Also, this will make Allison the > responsible > AD for the BoF. > > Hannes and I are working on organizing an agenda request now. What we need > most is some actual content, of course. Is anyone in this list interested > in > being a presenter, and if so, on what topics? We probably won't be asking > for a lot of time, and Hannes and I will present the proposed charter > itself, but it would be nice to have a small handful of focus > presentations > on the existing and/or planned work that the group would take on. > Presentations should be focused on requirements/problem space rather than > solutioning. > > Let us know. > > Jon Peterson > NeuStar, Inc. > > > _______________________________________________ > Sipping-emergency mailing list > Sipping-emergency@ietf.org > https://www1.ietf.org/mailman/listinfo/sipping-emergency > _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Fri Oct 15 13:50:48 2004 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 NAA24221 for ; Fri, 15 Oct 2004 13:50:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIWPU-0005P2-KB for sipping-emergency-web-archive@ietf.org; Fri, 15 Oct 2004 14:02:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIWD0-0000cs-R0; Fri, 15 Oct 2004 13:49:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIWB5-0000Ht-Uh for sipping-emergency@megatron.ietf.org; Fri, 15 Oct 2004 13:47:44 -0400 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 NAA24006 for ; Fri, 15 Oct 2004 13:47:42 -0400 (EDT) Received: from [206.173.41.176] (helo=sea-mailsweep-1.telecomsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIWMU-0005KD-JJ for sipping-emergency@ietf.org; Fri, 15 Oct 2004 13:59:31 -0400 Received: from sea-exchange-1.xypoint.com (unverified [10.32.12.12]) by sea-mailsweep-1.telecomsys.com (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Fri, 15 Oct 2004 10:47:10 -0700 Received: by sea-exchange-1.telecomsys.com with Internet Mail Service (5.5.2656.59) id <4RC2PL5H>; Fri, 15 Oct 2004 10:47:22 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A6575CE35AA@SEA-EXCHVS-2.telecomsys.com> From: Roger Marshall To: "Peterson, Jon" , sipping-emergency@ietf.org Subject: RE: [Sipping-emergency] New revision of proposed ECRIT charter Date: Fri, 15 Oct 2004 10:47:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-Spam-Score: 0.8 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Looks fine to me, whith amendments as suggested by others. Roger Marshall TCS -----Original Message----- From: sipping-emergency-bounces@ietf.org [mailto:sipping-emergency-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: Sunday, October 10, 2004 11:01 PM To: sipping-emergency@ietf.org Subject: [Sipping-emergency] New revision of proposed ECRIT charter All, Here's a new version of the ECRIT charter for your consideration, that attempts to incorporate the discussion over the past couple of weeks. Any further issues? Jon Peterson NeuStar, Inc. --- Emergency Context Resolution with Internet Technologies (ECRIT) Transport Area Director(s): Allison Mankin Jon Peterson Transport Area Advisor: TBD Working Group Chairs: TBD In a number of areas the public switched telephone network (PSTN) has been configured to recognize an explicitly specified number (commonly one that is short and easily memorized) as a call for emergency services. These numbers (e.g. 911, 112) relate to an emergency service context and depend on a broad, regional configuration of service contact methods and a geographically constrained context of service delivery. These calls are intended to be delivered to special call centers equipped to manage emergency response. Successful delivery of an emergency service call within those systems requires both an association of the physical location of the originator with an appropriate emergency service center and call routing to deliver the call to the center. Calls placed using Internet technologies do not use the same systems to achieve those goals, and the common use of overlay networks and tunnels (either as VPNs or for mobility) makes meeting them more challenging. There are, however, Internet technologies available to describe location and to manage call routing. This working group will describe when these may be appropriate and how they may be used. Explicitly outside the scope of this group is the question of pre-emption or prioritization of emergency services traffic. This group is considering emergency services calls which might be made by any user of the PSTN or Internet, as opposed to government or military services that may impose very different authentication and routing requirements. The group will show how the availability of location data and call routing information at different steps in session setup would enable communication between a user and a relevant emergency response center. Though the term "call routing" is used in this document, it should be understood that some of the mechanisms which will be described might be used to enable other types of media streams. Video and text messaging, for example, might be used to request emergency services. While this group anticipates a close working relationship with NENA, any solution presented must be useful regardless of jurisdiction, and it must be possible to use without a single, central authority. Further, it must be possible for multiple delegations within a jurisdiction to be handled independently, as call routing for specific emergency types may be indepdent. Deliverables: Informational RFC containing terminology definitions and the requirements. A BCP describing how to identify a session set-up request is to an emergency response center. A BCP describing strategies for associating session originators with physical locations. A BCP or Standards Track RFC describing how to route an emergency call based on location information. Either within that document or as a separate document, a description of how error conditions are returned to the session originator and how to test for error conditions without activating an emergency response. Privacy concerns related to that testing must be addressed in this document set. A BCP describing how to discover the media stream types an ERC supports. An Informational document describing the threats and security considerations. _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Fri Oct 15 13:54:19 2004 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 NAA24445 for ; Fri, 15 Oct 2004 13:54:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIWSt-0005TQ-Gv for sipping-emergency-web-archive@ietf.org; Fri, 15 Oct 2004 14:06:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIWD2-0000dH-Lv; Fri, 15 Oct 2004 13:49:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIWBM-0000IW-Mu for sipping-emergency@megatron.ietf.org; Fri, 15 Oct 2004 13:48:00 -0400 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 NAA24036 for ; Fri, 15 Oct 2004 13:47:55 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIWMi-0005Kl-Il for sipping-emergency@ietf.org; Fri, 15 Oct 2004 13:59:45 -0400 Received: from [128.59.16.206] (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i9FHlgDn025775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Oct 2004 13:47:49 -0400 (EDT) Message-ID: <41700D36.7040506@cs.columbia.edu> Date: Fri, 15 Oct 2004 13:47:34 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" Subject: Re: [Sipping-emergency] agenda items for ecrit References: <7927C67249E4AD43BC05B539AF0D129801AF4282@stntexch04.cis.neustar.com> In-Reply-To: <7927C67249E4AD43BC05B539AF0D129801AF4282@stntexch04.cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.10.14.6 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: sipping-emergency@ietf.org, "'Tschofenig Hannes'" X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit I would be delighted to present a summary of requirements (both those imposed by emergency service needs and those suggested by the likely future voice architecture) and a broad division of the problem space; as you know, I've been drafting these for a few years... Peterson, Jon wrote: > First of all, thanks to everyone who volunteered to chair the BoF. Allison > and I feel that for this initial meeting, it is probably more valuable for > everyone on this list to be able to appear as a participant and a supporter > of moving this effort forward. > > Accordingly, for the BoF, the chairs will be myself and Hannes Tschofenig. > Obviously, if this effort does go forward into a working group, I at least > won't be continuing as a chair. Also, this will make Allison the responsible > AD for the BoF. > > Hannes and I are working on organizing an agenda request now. What we need > most is some actual content, of course. Is anyone in this list interested in > being a presenter, and if so, on what topics? We probably won't be asking > for a lot of time, and Hannes and I will present the proposed charter > itself, but it would be nice to have a small handful of focus presentations > on the existing and/or planned work that the group would take on. > Presentations should be focused on requirements/problem space rather than > solutioning. > > Let us know. > > Jon Peterson > NeuStar, Inc. > > > _______________________________________________ > Sipping-emergency mailing list > Sipping-emergency@ietf.org > https://www1.ietf.org/mailman/listinfo/sipping-emergency _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Fri Oct 15 14:13:36 2004 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 OAA25906 for ; Fri, 15 Oct 2004 14:13:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIWlZ-0005vY-8z for sipping-emergency-web-archive@ietf.org; Fri, 15 Oct 2004 14:25:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIWW6-0004mg-Qx; Fri, 15 Oct 2004 14:09:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIWLg-0002WH-Pl for sipping-emergency@megatron.ietf.org; Fri, 15 Oct 2004 13:58:40 -0400 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 NAA24808 for ; Fri, 15 Oct 2004 13:58:39 -0400 (EDT) From: wilcox@e911.psd.state.vt.us Received: from static-64-222-94-65.burl.east.verizon.net ([64.222.94.65] helo=e911.psd.state.vt.us) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIWX5-0005aV-Ej for sipping-emergency@ietf.org; Fri, 15 Oct 2004 14:10:28 -0400 Content-Class: urn:content-classes:message Subject: RE: [Sipping-emergency] agenda items for ecrit MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Oct 2004 14:00:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: Thread-Topic: [Sipping-emergency] agenda items for ecrit Thread-Index: AcSy3hsUQN5rV/qwRkC0ZsRMRJsH+AAAHVyAAABb+qA= To: "Brian Rosen" , "Peterson, Jon" , X-Spam-Score: 0.3 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable Cc: Tschofenig Hannes X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable Brian's correct. I can't be there. Our staff is under minor travel = restrictions. I would be happy to assist Brian in creation of the = material and if a work group is created, I would also be willing to = contribute whatever is necesary.=20 Nate -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Friday, October 15, 2004 1:46 PM To: 'Peterson, Jon'; sipping-emergency@ietf.org Cc: 'Tschofenig Hannes' Subject: RE: [Sipping-emergency] agenda items for ecrit I would be willing to present on the problem space in North America and = how they are handled now. Nate might be a better presenter for that but I = don't think he can be there. =20 Brian > -----Original Message----- > From: sipping-emergency-bounces@ietf.org [mailto:sipping-emergency- > bounces@ietf.org] On Behalf Of Peterson, Jon > Sent: Friday, October 15, 2004 1:28 PM > To: sipping-emergency@ietf.org > Cc: 'Tschofenig Hannes' > Subject: [Sipping-emergency] agenda items for ecrit >=20 >=20 > First of all, thanks to everyone who volunteered to chair the BoF. = Allison > and I feel that for this initial meeting, it is probably more valuable = for > everyone on this list to be able to appear as a participant and a > supporter > of moving this effort forward. >=20 > Accordingly, for the BoF, the chairs will be myself and Hannes = Tschofenig. > Obviously, if this effort does go forward into a working group, I at = least > won't be continuing as a chair. Also, this will make Allison the > responsible > AD for the BoF. >=20 > Hannes and I are working on organizing an agenda request now. What we = need > most is some actual content, of course. Is anyone in this list = interested > in > being a presenter, and if so, on what topics? We probably won't be = asking > for a lot of time, and Hannes and I will present the proposed charter > itself, but it would be nice to have a small handful of focus > presentations > on the existing and/or planned work that the group would take on. > Presentations should be focused on requirements/problem space rather = than > solutioning. >=20 > Let us know. >=20 > Jon Peterson > NeuStar, Inc. >=20 >=20 > _______________________________________________ > Sipping-emergency mailing list > Sipping-emergency@ietf.org > https://www1.ietf.org/mailman/listinfo/sipping-emergency >=20 _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Fri Oct 15 15:27:40 2004 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 PAA01769 for ; Fri, 15 Oct 2004 15:27:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIXvF-0007Rm-Om for sipping-emergency-web-archive@ietf.org; Fri, 15 Oct 2004 15:39:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIXZV-0007kp-C5; Fri, 15 Oct 2004 15:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIXYQ-0007Et-1N for sipping-emergency@megatron.ietf.org; Fri, 15 Oct 2004 15:15:54 -0400 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 PAA00612 for ; Fri, 15 Oct 2004 15:15:51 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIXjo-0007Aq-Ez for sipping-emergency@ietf.org; Fri, 15 Oct 2004 15:27:42 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i9FJF2HC001137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 15 Oct 2004 12:15:02 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i9FJExba020362; Fri, 15 Oct 2004 12:15:00 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <41700D36.7040506@cs.columbia.edu> References: <7927C67249E4AD43BC05B539AF0D129801AF4282@stntexch04.cis.neustar.com> <41700D36.7040506@cs.columbia.edu> Date: Fri, 15 Oct 2004 12:14:58 -0700 To: Henning Schulzrinne , "Peterson, Jon" From: Ted Hardie Subject: Re: [Sipping-emergency] agenda items for ecrit Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: sipping-emergency@ietf.org, "'Tschofenig Hannes'" X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab I'd also be happy to present. I'm not sure whether what I'd like to discuss is actually "requirements", as Henning has volunteered for below, but more "considerations". There are clearly a number of design constraints in this problem space, and I'd like to put together a presentation that explores the ones of which I'm aware and starts the process of working towards consensus on how those constraints will circumscribe the work of the group. Ted At 1:47 PM -0400 10/15/04, Henning Schulzrinne wrote: >I would be delighted to present a summary of requirements (both >those imposed by emergency service needs and those suggested by the >likely future voice architecture) and a broad division of the >problem space; as you know, I've been drafting these for a few >years... > >Peterson, Jon wrote: >>First of all, thanks to everyone who volunteered to chair the BoF. Allison >>and I feel that for this initial meeting, it is probably more valuable for >>everyone on this list to be able to appear as a participant and a supporter >>of moving this effort forward. >> >>Accordingly, for the BoF, the chairs will be myself and Hannes Tschofenig. >>Obviously, if this effort does go forward into a working group, I at least >>won't be continuing as a chair. Also, this will make Allison the responsible >>AD for the BoF. >> >>Hannes and I are working on organizing an agenda request now. What we need >>most is some actual content, of course. Is anyone in this list interested in >>being a presenter, and if so, on what topics? We probably won't be asking >>for a lot of time, and Hannes and I will present the proposed charter >>itself, but it would be nice to have a small handful of focus presentations >>on the existing and/or planned work that the group would take on. >>Presentations should be focused on requirements/problem space rather than >>solutioning. >> >>Let us know. >> >>Jon Peterson >>NeuStar, Inc. >> >> >>_______________________________________________ >>Sipping-emergency mailing list >>Sipping-emergency@ietf.org >>https://www1.ietf.org/mailman/listinfo/sipping-emergency > >_______________________________________________ >Sipping-emergency mailing list >Sipping-emergency@ietf.org >https://www1.ietf.org/mailman/listinfo/sipping-emergency _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Sun Oct 17 12:33:17 2004 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 MAA04970 for ; Sun, 17 Oct 2004 12:33:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJEA1-0002Sp-19 for sipping-emergency-web-archive@ietf.org; Sun, 17 Oct 2004 12:45:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJDx2-0005sl-Pf; Sun, 17 Oct 2004 12:32:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJDwb-0005kL-A0 for sipping-emergency@megatron.ietf.org; Sun, 17 Oct 2004 12:31:41 -0400 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 MAA04803 for ; Sun, 17 Oct 2004 12:31:38 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJE8Q-0002QT-4W for sipping-emergency@ietf.org; Sun, 17 Oct 2004 12:43:54 -0400 Received: from razor.cs.columbia.edu (IDENT:O6ArjT9EuCzvi7YwUSfDrORq7J0vL6vt@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i9HGVWx6006408 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Sun, 17 Oct 2004 12:31:32 -0400 (EDT) Received: from [127.0.0.1] (IDENT:6c7ITvrXNti7TDTrMCrjPzIFdpfSFK5o@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i9HGVVYZ007527 for ; Sun, 17 Oct 2004 12:31:31 -0400 Message-ID: <41729E63.5000904@cs.columbia.edu> Date: Sun, 17 Oct 2004 12:31:31 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping-emergency@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.10.16.1 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Subject: [Sipping-emergency] Two related drafts X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit I will be submitting two draft updates shortly: http://www.cs.columbia.edu/sip/draft/emergency-req/draft-schulzrinne-sipping-emergency-req-01.html http://www.cs.columbia.edu/sip/draft/emergency-arch/draft-schulzrinne-sipping-emergency-arch-02.html Maybe these can be part of the reading list for the BOF. (Comments are welcome; the draft names reflect their previous non-home...) Henning _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Mon Oct 18 18:41:38 2004 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 SAA01847 for ; Mon, 18 Oct 2004 18:41:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJgOH-0003Vo-FZ for sipping-emergency-web-archive@ietf.org; Mon, 18 Oct 2004 18:54:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJfm4-0004FG-VS; Mon, 18 Oct 2004 18:14:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJfTn-0004AX-2W for sipping-emergency@megatron.ietf.org; Mon, 18 Oct 2004 17:55:47 -0400 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 RAA27812 for ; Mon, 18 Oct 2004 17:55:39 -0400 (EDT) Received: from ns1.sccx.com ([199.117.205.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJffm-0002fp-EN for sipping-emergency@ietf.org; Mon, 18 Oct 2004 18:08:11 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping-emergency] agenda items for ecrit X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 18 Oct 2004 16:55:07 -0500 Message-ID: <422D410BD61FC04185076AD99AA7207A5DA1A6@inilmx01.lgmt.trdo> Thread-Topic: [Sipping-emergency] agenda items for ecrit Thread-Index: AcSy3hsUQN5rV/qwRkC0ZsRMRJsH+AAAHVyAAABb+qAAnzqHcA== From: "McCalmont, Patti" To: X-OriginalArrivalTime: 18 Oct 2004 21:55:08.0817 (UTC) FILETIME=[22793010:01C4B55D] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable Cc: Tschofenig Hannes X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: quoted-printable Where is this meeting going to be held and when. I missed that email. Thanks, Patti McCalmont -----Original Message----- From: sipping-emergency-bounces@ietf.org [mailto:sipping-emergency-bounces@ietf.org] On Behalf Of wilcox@e911.psd.state.vt.us Sent: Friday, October 15, 2004 1:00 PM To: Brian Rosen; Peterson, Jon; sipping-emergency@ietf.org Cc: Tschofenig Hannes Subject: RE: [Sipping-emergency] agenda items for ecrit Brian's correct. I can't be there. Our staff is under minor travel restrictions. I would be happy to assist Brian in creation of the material and if a work group is created, I would also be willing to contribute whatever is necesary.=20 Nate -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Friday, October 15, 2004 1:46 PM To: 'Peterson, Jon'; sipping-emergency@ietf.org Cc: 'Tschofenig Hannes' Subject: RE: [Sipping-emergency] agenda items for ecrit I would be willing to present on the problem space in North America and how they are handled now. Nate might be a better presenter for that but I don't think he can be there. =20 Brian > -----Original Message----- > From: sipping-emergency-bounces@ietf.org [mailto:sipping-emergency-=20 > bounces@ietf.org] On Behalf Of Peterson, Jon > Sent: Friday, October 15, 2004 1:28 PM > To: sipping-emergency@ietf.org > Cc: 'Tschofenig Hannes' > Subject: [Sipping-emergency] agenda items for ecrit >=20 >=20 > First of all, thanks to everyone who volunteered to chair the BoF.=20 > Allison and I feel that for this initial meeting, it is probably more=20 > valuable for everyone on this list to be able to appear as a=20 > participant and a supporter of moving this effort forward. >=20 > Accordingly, for the BoF, the chairs will be myself and Hannes Tschofenig. > Obviously, if this effort does go forward into a working group, I at=20 > least won't be continuing as a chair. Also, this will make Allison the > responsible AD for the BoF. >=20 > Hannes and I are working on organizing an agenda request now. What we=20 > need most is some actual content, of course. Is anyone in this list=20 > interested in being a presenter, and if so, on what topics? We=20 > probably won't be asking for a lot of time, and Hannes and I will=20 > present the proposed charter itself, but it would be nice to have a=20 > small handful of focus presentations on the existing and/or planned=20 > work that the group would take on. > Presentations should be focused on requirements/problem space rather=20 > than solutioning. >=20 > Let us know. >=20 > Jon Peterson > NeuStar, Inc. >=20 >=20 > _______________________________________________ > Sipping-emergency mailing list > Sipping-emergency@ietf.org > https://www1.ietf.org/mailman/listinfo/sipping-emergency >=20 _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Thu Oct 21 11:14:02 2004 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 LAA11880 for ; Thu, 21 Oct 2004 11:14:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKeqJ-0005hF-JQ for sipping-emergency-web-archive@ietf.org; Thu, 21 Oct 2004 11:27:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKeXt-0006G1-5t; Thu, 21 Oct 2004 11:08:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKeOS-0002OL-FD for sipping-emergency@megatron.ietf.org; Thu, 21 Oct 2004 10:58:20 -0400 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 KAA10193 for ; Thu, 21 Oct 2004 10:58:13 -0400 (EDT) Received: from dnsmx1pya.telcordia.com ([128.96.20.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKeb0-0005Gb-F9 for sipping-emergency@ietf.org; Thu, 21 Oct 2004 11:11:20 -0400 Received: from rrc-its-ieg02.cc.telcordia.com (rrc-its-ieg02.cc.telcordia.com [128.96.109.3]) by dnsmx1pya.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id i9LEva220287; Thu, 21 Oct 2004 10:57:36 -0400 (EDT) Received: from rrc-its-exig01.mail.saic.com ([128.96.103.57]) by rrc-its-ieg02.cc.telcordia.com (SAVSMTP 3.1.6.45) with SMTP id M2004102110573413908 ; Thu, 21 Oct 2004 10:57:34 -0400 Received: by rrc-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Thu, 21 Oct 2004 10:57:35 -0400 Message-ID: From: "Abbott, Nadine B." To: "Peterson, Jon" Subject: RE: [Sipping-emergency] New revision of proposed ECRIT charter Date: Thu, 21 Oct 2004 10:57:34 -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: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: sipping-emergency@ietf.org X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Jon, In the North American National Emergency Number Association (NENA) VoIP Location WG, we have been grappling with the problem of how additional information relevant to an emergency call might be carried to the emergency call taker. For example, this might include information about the caller (e.g., Customer Name, Class of Service--Residence, Business, Public, etc.) and information about/from a VoIP/Communications Service Provider (e.g., contact information for that provider) that are relevant to an emergency call. We are not yet ready (before this next meeting) to provide a list of proposed requirements. However, I wondered if you consider that the charter for ECRIT, as written, covers the issue of how such information--caller supplied and/or service provider supplied--might be carried in SIP? Respectfully, Nadine Abbott NENA VoIP Location WG team leader _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Thu Oct 21 11:49:26 2004 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 LAA15337 for ; Thu, 21 Oct 2004 11:49:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKfOZ-0006Tk-Th for sipping-emergency-web-archive@ietf.org; Thu, 21 Oct 2004 12:02:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKf4D-0004bZ-2z; Thu, 21 Oct 2004 11:41:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKewv-0001cM-Vb for sipping-emergency@megatron.ietf.org; Thu, 21 Oct 2004 11:33:58 -0400 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 LAA13795 for ; Thu, 21 Oct 2004 11:33:55 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKf9Y-00067X-P6 for sipping-emergency@ietf.org; Thu, 21 Oct 2004 11:47:02 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 21 Oct 2004 08:34:04 -0700 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i9LFXN9b003882; Thu, 21 Oct 2004 08:33:23 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA27103; Thu, 21 Oct 2004 08:33:22 -0700 (PDT) Message-Id: <4.3.2.7.2.20041021103008.02915808@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Oct 2004 10:33:21 -0500 To: "Abbott, Nadine B." , "Peterson, Jon" From: "James M. Polk" Subject: RE: [Sipping-emergency] New revision of proposed ECRIT charter In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: sipping-emergency@ietf.org X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Isn't most of this an extension to the PIDF-LO effort in Geopriv, and not part of ECRIT? The portion that I believe is part of SIP/PING would be the addition of a body part by the VSP (in add the contact info you want) - which has so far been frowned upon (to say the least) in these WGs At 10:57 AM 10/21/2004 -0400, Abbott, Nadine B. wrote: >Jon, > >In the North American National Emergency Number Association (NENA) VoIP >Location WG, we have been grappling with the problem of how additional >information relevant to an emergency call might be carried to the emergency >call taker. For example, this might include information about the caller >(e.g., Customer Name, Class of Service--Residence, Business, Public, etc.) >and information about/from a VoIP/Communications Service Provider (e.g., >contact information for that provider) that are relevant to an emergency >call. We are not yet ready (before this next meeting) to provide a list of >proposed requirements. >However, I wondered if you consider that the charter for ECRIT, as written, >covers the issue of how such information--caller supplied and/or service >provider supplied--might be carried in SIP? > >Respectfully, >Nadine Abbott >NENA VoIP Location WG team leader > >_______________________________________________ >Sipping-emergency mailing list >Sipping-emergency@ietf.org >https://www1.ietf.org/mailman/listinfo/sipping-emergency cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Wed Oct 27 09:51:06 2004 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 JAA04217 for ; Wed, 27 Oct 2004 09:51:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMoQa-0005be-KT for sipping-emergency-web-archive@ietf.org; Wed, 27 Oct 2004 10:05:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMo7G-0007fM-3s; Wed, 27 Oct 2004 09:45:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMo36-0006qq-J7 for sipping-emergency@megatron.ietf.org; Wed, 27 Oct 2004 09:41:12 -0400 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 JAA03838 for ; Wed, 27 Oct 2004 09:41:10 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMoGx-0005R2-Mp for sipping-emergency@ietf.org; Wed, 27 Oct 2004 09:55:33 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 27 Oct 2004 06:52:04 -0700 X-BrightmailFiltered: true Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9RDeTk2003295 for ; Wed, 27 Oct 2004 06:40:29 -0700 (PDT) Received: from mlinsnerzk7abh (ssh-sjc-1.cisco.com [171.68.225.134]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA14621 for ; Wed, 27 Oct 2004 06:40:36 -0700 (PDT) From: "Marc Linsner" To: Date: Wed, 27 Oct 2004 09:40:37 -0400 Message-ID: <008501c4bc2a$8b5aab80$210d0d0a@mlinsnerzk7abh> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Spam-Score: 1.1 (+) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit Subject: [Sipping-emergency] BOF in DC X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Has a BOF been scheduled? Trying to make travel arraigments........ -Marc Linsner- _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Thu Oct 28 04:17:59 2004 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 EAA18143 for ; Thu, 28 Oct 2004 04:17:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN5hv-0003Bv-5x for sipping-emergency-web-archive@ietf.org; Thu, 28 Oct 2004 04:32:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN5TU-00016G-Si; Thu, 28 Oct 2004 04:17:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN5Rd-0000oP-Lc for sipping-emergency@megatron.ietf.org; Thu, 28 Oct 2004 04:15:41 -0400 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 EAA17846 for ; Thu, 28 Oct 2004 04:15:39 -0400 (EDT) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN5ff-00038W-DE for sipping-emergency@ietf.org; Thu, 28 Oct 2004 04:30:11 -0400 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id i9S8E1Pm012455; Thu, 28 Oct 2004 08:14:01 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Thu, 28 Oct 2004 04:14:01 -0400 Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF42FA@stntexch04.cis.neustar.com> From: "Peterson, Jon" To: "'Marc Linsner'" , sipping-emergency@ietf.org Subject: RE: [Sipping-emergency] BOF in DC Date: Thu, 28 Oct 2004 04:13:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 The draft agenda lists ECRIT on Friday. However, there is already a conflict at that time, and things will shuffle around a bit before the agenda is finalized. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Wednesday, October 27, 2004 6:41 AM > To: sipping-emergency@ietf.org > Subject: [Sipping-emergency] BOF in DC > > > Has a BOF been scheduled? > > Trying to make travel arraigments........ > > -Marc Linsner- > > > _______________________________________________ > Sipping-emergency mailing list > Sipping-emergency@ietf.org > https://www1.ietf.org/mailman/listinfo/sipping-emergency > _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Thu Oct 28 05:24:57 2004 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 FAA22985 for ; Thu, 28 Oct 2004 05:24:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN6kj-0004XJ-Ea for sipping-emergency-web-archive@ietf.org; Thu, 28 Oct 2004 05:39:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN6VW-0002Kw-Ei; Thu, 28 Oct 2004 05:23:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN6SQ-0001j7-90 for sipping-emergency@megatron.ietf.org; Thu, 28 Oct 2004 05:20:34 -0400 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 FAA22706 for ; Thu, 28 Oct 2004 05:20:32 -0400 (EDT) Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN6gS-0004ST-N5 for sipping-emergency@ietf.org; Thu, 28 Oct 2004 05:35:05 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id i9S9KUP6011718; Thu, 28 Oct 2004 11:20:30 +0200 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id i9S9KTBO026793; Thu, 28 Oct 2004 11:20:29 +0200 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <4BVR7K5C>; Thu, 28 Oct 2004 11:20:29 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F051C88C0@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "James M. Polk" , "Abbott, Nadine B." , "Peterson, Jon" Subject: RE: [Sipping-emergency] New revision of proposed ECRIT charter Date: Thu, 28 Oct 2004 11:20:25 +0200 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: cd26b070c2577ac175cd3a6d878c6248 Cc: sipping-emergency@ietf.org X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 hi james, some data items seem to be part of the pidf-lo work. however, as nadine mentioned there are additional fields: - Customer Name, - Class of Service--Residence, Business, Public, etc. - information about/from a VoIP/Communications Service Provider this information is not included in the pidf-lo. is this use case for saml you are often talking about? ciao hannes > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Donnerstag, 21. Oktober 2004 17:33 > To: Abbott, Nadine B.; Peterson, Jon > Cc: sipping-emergency@ietf.org > Subject: RE: [Sipping-emergency] New revision of proposed > ECRIT charter > > Isn't most of this an extension to the PIDF-LO effort in > Geopriv, and not part of ECRIT? > > The portion that I believe is part of SIP/PING would be the > addition of a body part by the VSP (in add the contact info > you want) - which has so far been frowned upon (to say the > least) in these WGs > > At 10:57 AM 10/21/2004 -0400, Abbott, Nadine B. wrote: > >Jon, > > > >In the North American National Emergency Number Association > (NENA) VoIP > >Location WG, we have been grappling with the problem of how > additional > >information relevant to an emergency call might be carried to the > emergency > >call taker. For example, this might include information about the > caller > >(e.g., Customer Name, Class of Service--Residence, Business, Public, > etc.) > >and information about/from a VoIP/Communications Service Provider > (e.g., > >contact information for that provider) that are relevant to an > emergency > >call. We are not yet ready (before this next meeting) to provide a > list of > >proposed requirements. > >However, I wondered if you consider that the charter for ECRIT, as > written, > >covers the issue of how such information--caller supplied and/or > service > >provider supplied--might be carried in SIP? > > > >Respectfully, > >Nadine Abbott > >NENA VoIP Location WG team leader > > > >_______________________________________________ > >Sipping-emergency mailing list > >Sipping-emergency@ietf.org > >https://www1.ietf.org/mailman/listinfo/sipping-emergency > > > cheers, > James > > ******************* > Truth is not to be argued... it is to be presented > > > _______________________________________________ > Sipping-emergency mailing list > Sipping-emergency@ietf.org > https://www1.ietf.org/mailman/listinfo/sipping-emergency > _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Thu Oct 28 05:30:56 2004 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 FAA23338 for ; Thu, 28 Oct 2004 05:30:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN6qX-0004ev-4m for sipping-emergency-web-archive@ietf.org; Thu, 28 Oct 2004 05:45:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN6aU-0003Nt-3K; Thu, 28 Oct 2004 05:28:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN6Xr-0002k6-65 for sipping-emergency@megatron.ietf.org; Thu, 28 Oct 2004 05:26:11 -0400 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 FAA23040 for ; Thu, 28 Oct 2004 05:26:09 -0400 (EDT) Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN6ls-0004YL-RT for sipping-emergency@ietf.org; Thu, 28 Oct 2004 05:40:42 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id i9S9Q8BO029899; Thu, 28 Oct 2004 11:26:08 +0200 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id i9S9Q8BO032467; Thu, 28 Oct 2004 11:26:08 +0200 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <4BVR7K9K>; Thu, 28 Oct 2004 11:26:07 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F051C88C3@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: James Winterbottom Date: Thu, 28 Oct 2004 11:26:07 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.8 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: sipping-emergency@ietf.org Subject: [Sipping-emergency] RE: draft requirements for ECRIT: draft-winterbottom-ecrit-locati on-s cope-req-00 X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa hi james, thanks for the draft. you might want to announce it at the sipping-emergency@ietf.org mailing list. ciao hannes > -----Original Message----- > From: James Winterbottom [mailto:winterb@nortelnetworks.com] > Sent: Montag, 18. Oktober 2004 16:14 > To: 'internet-drafts@ietf.org' > Cc: jon.peterson@neustar.biz; Tschofenig Hannes; Martin > Dawson; Martin Thomson > Subject: draft requirements for ECRIT: > draft-winterbottom-ecrit-location-s cope-req-00 > > Attached, please find a draft being submitted for discussion > in the ECRIT WG. > > Abstract > > Special kinds of services require user location > information to be authenticated and validated within a > specific operating domain. An example of such a service is > the emergency services network, where the location of a > caller is known with in the domain of the telephone network, > while the name or true identity of the caller is not > intrinsically known. This paper describes the entities and > key requirements necessary to provide such a service an > internet environment. > > Regards > James Winterbottom > winterb@nortelnetworks.com > 61-2-42-233038 > > <> > > _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Thu Oct 28 10:03:38 2004 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 KAA14487 for ; Thu, 28 Oct 2004 10:03:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNB6T-0001u7-1z for sipping-emergency-web-archive@ietf.org; Thu, 28 Oct 2004 10:18:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNAl2-0001Ea-LH; Thu, 28 Oct 2004 09:56:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNAeR-00080N-9p for sipping-emergency@megatron.ietf.org; Thu, 28 Oct 2004 09:49:16 -0400 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 JAA13093 for ; Thu, 28 Oct 2004 09:49:09 -0400 (EDT) Received: from dnsmx2pya.telcordia.com ([128.96.20.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNAsP-0001TX-8w for sipping-emergency@ietf.org; Thu, 28 Oct 2004 10:03:44 -0400 Received: from rrc-its-ieg02.cc.telcordia.com (rrc-its-ieg02.cc.telcordia.com [128.96.109.3]) by dnsmx2pya.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id i9SDm0g03672; Thu, 28 Oct 2004 09:48:00 -0400 (EDT) Received: from rrc-its-exbh01.mail.saic.com ([128.96.109.61]) by rrc-its-ieg02.cc.telcordia.com (SAVSMTP 3.1.6.45) with SMTP id M2004102809475831083 ; Thu, 28 Oct 2004 09:47:58 -0400 Received: by rrc-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2657.72) id <409CTL3K>; Thu, 28 Oct 2004 09:47:58 -0400 Message-ID: From: "Abbott, Nadine B." To: James Winterbottom Subject: RE: [Sipping-emergency] RE: draft requirements for ECRIT: draft-w interbottom-ecrit-locati on-s cope-req-00 Date: Thu, 28 Oct 2004 09:47:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.8 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: sipping-emergency@ietf.org X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Hi, James, Could I have a copy too? Thanks, Nadine -----Original Message----- From: sipping-emergency-bounces@ietf.org [mailto:sipping-emergency-bounces@ietf.org] On Behalf Of Tschofenig Hannes Sent: Thursday, October 28, 2004 5:26 AM To: James Winterbottom Cc: sipping-emergency@ietf.org Subject: [Sipping-emergency] RE: draft requirements for ECRIT: draft-winterbottom-ecrit-locati on-s cope-req-00 hi james, thanks for the draft. you might want to announce it at the sipping-emergency@ietf.org mailing list. ciao hannes > -----Original Message----- > From: James Winterbottom [mailto:winterb@nortelnetworks.com] > Sent: Montag, 18. Oktober 2004 16:14 > To: 'internet-drafts@ietf.org' > Cc: jon.peterson@neustar.biz; Tschofenig Hannes; Martin > Dawson; Martin Thomson > Subject: draft requirements for ECRIT: > draft-winterbottom-ecrit-location-s cope-req-00 > > Attached, please find a draft being submitted for discussion > in the ECRIT WG. > > Abstract > > Special kinds of services require user location > information to be authenticated and validated within a > specific operating domain. An example of such a service is > the emergency services network, where the location of a > caller is known with in the domain of the telephone network, > while the name or true identity of the caller is not > intrinsically known. This paper describes the entities and > key requirements necessary to provide such a service an > internet environment. > > Regards > James Winterbottom > winterb@nortelnetworks.com > 61-2-42-233038 > > <> > > _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Thu Oct 28 10:15:53 2004 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 KAA15962 for ; Thu, 28 Oct 2004 10:15:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNBII-0002CE-TN for sipping-emergency-web-archive@ietf.org; Thu, 28 Oct 2004 10:30:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNB1x-00085q-S1; Thu, 28 Oct 2004 10:13:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNAyp-00073G-2S for sipping-emergency@megatron.ietf.org; Thu, 28 Oct 2004 10:10:19 -0400 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 KAA15205 for ; Thu, 28 Oct 2004 10:10:18 -0400 (EDT) Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNBCu-00023F-98 for sipping-emergency@ietf.org; Thu, 28 Oct 2004 10:24:53 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id i9SEAAfO014439; Thu, 28 Oct 2004 16:10:10 +0200 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id i9SEAABO024128; Thu, 28 Oct 2004 16:10:10 +0200 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <4BVR7RRW>; Thu, 28 Oct 2004 16:10:10 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F05319C13@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "Abbott, Nadine B." , James Winterbottom Subject: RE: [Sipping-emergency] RE: draft requirements for ECRIT: draft-w interbottom-ecrit-locati on-s cope-req-00 Date: Thu, 28 Oct 2004 16:10:08 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.8 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sipping-emergency@ietf.org X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 hi all, hmm. i wasn't able to retrieve it from the ietf archive. please find a copy at http://www.tschofenig.priv.at/TEMP/draft-winterbottom-ecrit-location-scope-req-0 0.txt ciao hannes > -----Original Message----- > From: Abbott, Nadine B. [mailto:nabbott@telcordia.com] > Sent: Donnerstag, 28. Oktober 2004 15:48 > To: James Winterbottom > Cc: sipping-emergency@ietf.org > Subject: RE: [Sipping-emergency] RE: draft requirements for > ECRIT: draft-w interbottom-ecrit-locati on-s cope-req-00 > > Hi, James, > Could I have a copy too? > Thanks, > Nadine > > -----Original Message----- > From: sipping-emergency-bounces@ietf.org > [mailto:sipping-emergency-bounces@ietf.org] On Behalf Of > Tschofenig Hannes > Sent: Thursday, October 28, 2004 5:26 AM > To: James Winterbottom > Cc: sipping-emergency@ietf.org > Subject: [Sipping-emergency] RE: draft requirements for ECRIT: > draft-winterbottom-ecrit-locati on-s cope-req-00 > > > hi james, > > thanks for the draft. you might want to announce it at the > sipping-emergency@ietf.org mailing list. > > ciao > hannes > > > > -----Original Message----- > > From: James Winterbottom [mailto:winterb@nortelnetworks.com] > > Sent: Montag, 18. Oktober 2004 16:14 > > To: 'internet-drafts@ietf.org' > > Cc: jon.peterson@neustar.biz; Tschofenig Hannes; Martin > Dawson; Martin > > Thomson > > Subject: draft requirements for ECRIT: > > draft-winterbottom-ecrit-location-s cope-req-00 > > > > Attached, please find a draft being submitted for discussion in the > > ECRIT WG. > > > > Abstract > > > > Special kinds of services require user location > information to be > > authenticated and validated within a specific operating domain. An > > example of such a service is the emergency services > network, where the > > location of a caller is known with in the domain of the telephone > > network, while the name or true identity of the caller is not > > intrinsically known. This paper describes the entities and key > > requirements necessary to provide such a service an internet > > environment. > > > > Regards > > James Winterbottom > > winterb@nortelnetworks.com > > 61-2-42-233038 > > > > <> > > > > > > _______________________________________________ > Sipping-emergency mailing list > Sipping-emergency@ietf.org > https://www1.ietf.org/mailman/listinfo/sipping-emergency > > _______________________________________________ > Sipping-emergency mailing list > Sipping-emergency@ietf.org > https://www1.ietf.org/mailman/listinfo/sipping-emergency > _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Thu Oct 28 10:16:18 2004 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 KAA16023 for ; Thu, 28 Oct 2004 10:16:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNBIj-0002DC-25 for sipping-emergency-web-archive@ietf.org; Thu, 28 Oct 2004 10:30:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNB20-00086p-0h; Thu, 28 Oct 2004 10:13:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNB0U-0007du-WC for sipping-emergency@megatron.ietf.org; Thu, 28 Oct 2004 10:12:03 -0400 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 KAA15495 for ; Thu, 28 Oct 2004 10:12:02 -0400 (EDT) Message-Id: <200410281412.KAA15495@ietf.org> Received: from winwebhosting.com ([67.15.20.8] helo=dx24.winwebhosting.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNBEQ-00024n-IE for sipping-emergency@ietf.org; Thu, 28 Oct 2004 10:26:37 -0400 Received: from acs-24-154-127-195.zoominternet.net ([24.154.127.195] helo=BROSENLT) by dx24.winwebhosting.com with esmtpa (Exim 4.43) id 1CNAzQ-0002YT-Tc; Thu, 28 Oct 2004 09:10:57 -0500 From: "Brian Rosen" To: "'Abbott, Nadine B.'" , "'James Winterbottom'" Subject: RE: [Sipping-emergency] RE: draft requirements for ECRIT: draft-winterbottom-ecrit-locati on-s cope-req-00 Date: Thu, 28 Oct 2004 10:10:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcS89uVoaHoxLd2rSJyx6yRQ/my3YgAALfKQ In-Reply-To: X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx24.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.8 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit Cc: sipping-emergency@ietf.org X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 1.5 (+) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit This draft appears to have not been submitted. The ietf-announce list is pretty quiet, I think they have announced all that there is, and it's not there. A determined search for it with google yielded no results. Why don't you put it on a website somewhere and send an email to this list with a url to it. I can do that for you if it would be helpful. Brian > -----Original Message----- > From: sipping-emergency-bounces@ietf.org [mailto:sipping-emergency- > bounces@ietf.org] On Behalf Of Abbott, Nadine B. > Sent: Thursday, October 28, 2004 9:48 AM > To: James Winterbottom > Cc: sipping-emergency@ietf.org > Subject: RE: [Sipping-emergency] RE: draft requirements for ECRIT: draft- > winterbottom-ecrit-locati on-s cope-req-00 > > Hi, James, > Could I have a copy too? > Thanks, > Nadine > > -----Original Message----- > From: sipping-emergency-bounces@ietf.org > [mailto:sipping-emergency-bounces@ietf.org] On Behalf Of Tschofenig Hannes > Sent: Thursday, October 28, 2004 5:26 AM > To: James Winterbottom > Cc: sipping-emergency@ietf.org > Subject: [Sipping-emergency] RE: draft requirements for ECRIT: > draft-winterbottom-ecrit-locati on-s cope-req-00 > > > hi james, > > thanks for the draft. you might want to announce it at the > sipping-emergency@ietf.org mailing list. > > ciao > hannes > > > > -----Original Message----- > > From: James Winterbottom [mailto:winterb@nortelnetworks.com] > > Sent: Montag, 18. Oktober 2004 16:14 > > To: 'internet-drafts@ietf.org' > > Cc: jon.peterson@neustar.biz; Tschofenig Hannes; Martin > > Dawson; Martin Thomson > > Subject: draft requirements for ECRIT: > > draft-winterbottom-ecrit-location-s cope-req-00 > > > > Attached, please find a draft being submitted for discussion > > in the ECRIT WG. > > > > Abstract > > > > Special kinds of services require user location > > information to be authenticated and validated within a > > specific operating domain. An example of such a service is > > the emergency services network, where the location of a > > caller is known with in the domain of the telephone network, > > while the name or true identity of the caller is not > > intrinsically known. This paper describes the entities and > > key requirements necessary to provide such a service an > > internet environment. > > > > Regards > > James Winterbottom > > winterb@nortelnetworks.com > > 61-2-42-233038 > > > > <> > > > > > > _______________________________________________ > Sipping-emergency mailing list > Sipping-emergency@ietf.org > https://www1.ietf.org/mailman/listinfo/sipping-emergency > > _______________________________________________ > Sipping-emergency mailing list > Sipping-emergency@ietf.org > https://www1.ietf.org/mailman/listinfo/sipping-emergency > _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Thu Oct 28 15:54:38 2004 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 PAA28386 for ; Thu, 28 Oct 2004 15:54:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNGa8-00080U-1P for sipping-emergency-web-archive@ietf.org; Thu, 28 Oct 2004 16:09:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CND3f-0002ti-V4; Thu, 28 Oct 2004 12:23:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNCac-0003JX-92 for sipping-emergency@megatron.ietf.org; Thu, 28 Oct 2004 11:53:26 -0400 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 LAA04193 for ; Thu, 28 Oct 2004 11:53:24 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNCoi-0007Bk-70 for sipping-emergency@ietf.org; Thu, 28 Oct 2004 12:08:00 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 28 Oct 2004 09:04:54 -0700 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i9SFrF6s023637; Thu, 28 Oct 2004 08:53:15 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA08289; Thu, 28 Oct 2004 08:53:14 -0700 (PDT) Message-Id: <4.3.2.7.2.20041028105119.0282cea8@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Oct 2004 10:53:15 -0500 To: Tschofenig Hannes , "Abbott, Nadine B." , "Peterson, Jon" From: "James M. Polk" Subject: RE: [Sipping-emergency] New revision of proposed ECRIT charter In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F051C88C0@mchp905a.mch.sbs. de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: sipping-emergency@ietf.org X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b At 11:20 AM 10/28/2004 +0200, Tschofenig Hannes wrote: >hi james, > >some data items seem to be part of the pidf-lo work. each of items below are or are not part of the pidf-lo. No other fields in a SIP message should carry them, therefore this is part of the geopriv wg >however, as nadine >mentioned there are additional fields: >- Customer Name, >- Class of Service--Residence, Business, Public, etc. >- information about/from a VoIP/Communications Service Provider > >this information is not included in the pidf-lo. > >is this use case for saml you are often talking about? saml asserts a trait, which none of the above are, each above is individual or personal, not a trait >ciao >hannes > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: Donnerstag, 21. Oktober 2004 17:33 > > To: Abbott, Nadine B.; Peterson, Jon > > Cc: sipping-emergency@ietf.org > > Subject: RE: [Sipping-emergency] New revision of proposed > > ECRIT charter > > > > Isn't most of this an extension to the PIDF-LO effort in > > Geopriv, and not part of ECRIT? > > > > The portion that I believe is part of SIP/PING would be the > > addition of a body part by the VSP (in add the contact info > > you want) - which has so far been frowned upon (to say the > > least) in these WGs > > > > At 10:57 AM 10/21/2004 -0400, Abbott, Nadine B. wrote: > > >Jon, > > > > > >In the North American National Emergency Number Association > > (NENA) VoIP > > >Location WG, we have been grappling with the problem of how > > additional > > >information relevant to an emergency call might be carried to the > > emergency > > >call taker. For example, this might include information about the > > caller > > >(e.g., Customer Name, Class of Service--Residence, Business, Public, > > etc.) > > >and information about/from a VoIP/Communications Service Provider > > (e.g., > > >contact information for that provider) that are relevant to an > > emergency > > >call. We are not yet ready (before this next meeting) to provide a > > list of > > >proposed requirements. > > >However, I wondered if you consider that the charter for ECRIT, as > > written, > > >covers the issue of how such information--caller supplied and/or > > service > > >provider supplied--might be carried in SIP? > > > > > >Respectfully, > > >Nadine Abbott > > >NENA VoIP Location WG team leader > > > > > >_______________________________________________ > > >Sipping-emergency mailing list > > >Sipping-emergency@ietf.org > > >https://www1.ietf.org/mailman/listinfo/sipping-emergency > > > > > > cheers, > > James > > > > ******************* > > Truth is not to be argued... it is to be presented > > > > > > _______________________________________________ > > Sipping-emergency mailing list > > Sipping-emergency@ietf.org > > https://www1.ietf.org/mailman/listinfo/sipping-emergency > > cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Thu Oct 28 18:55:19 2004 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 SAA03791 for ; Thu, 28 Oct 2004 18:55:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNJP5-0001Ta-UN for sipping-emergency-web-archive@ietf.org; Thu, 28 Oct 2004 19:10:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNGF1-00037o-M2; Thu, 28 Oct 2004 15:47:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNCoN-0006KN-2d for sipping-emergency@megatron.ietf.org; Thu, 28 Oct 2004 12:07:39 -0400 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 MAA07461 for ; Thu, 28 Oct 2004 12:07:37 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CND2T-0008F7-9L for sipping-emergency@ietf.org; Thu, 28 Oct 2004 12:22:13 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 28 Oct 2004 09:16:24 -0700 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9SG6vk2025209; Thu, 28 Oct 2004 09:06:57 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA02950; Thu, 28 Oct 2004 09:07:03 -0700 (PDT) Message-Id: <4.3.2.7.2.20041028105612.03104540@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Oct 2004 11:06:49 -0500 To: "Brian Rosen" , "'Abbott, Nadine B.'" , "'James Winterbottom'" From: "James M. Polk" Subject: RE: [Sipping-emergency] RE: draft requirements for ECRIT: draft-winterbottom-ecrit-locati on-s cope-req-00 In-Reply-To: <200410281412.KAA15495@ietf.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.9 (+) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: sipping-emergency@ietf.org X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 1.9 (+) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 At 10:10 AM 10/28/2004 -0400, Brian Rosen wrote: >This draft appears to have not been submitted. as a matter of IETF procedure, IDs not submitted on time (therefore not submitted) will not be discussed at IETF meetings.... come on guys, we know the rules here 2418 states this, and this was discussed at length on the open main IETF list Oct 18th through the 20th by over a dozen folks. >The ietf-announce list is >pretty quiet, I think they have announced all that there is, and it's not >there. > >A determined search for it with google yielded no results. > >Why don't you put it on a website somewhere and send an email to this list >with a url to it. I can do that for you if it would be helpful. > >Brian > > > -----Original Message----- > > From: sipping-emergency-bounces@ietf.org [mailto:sipping-emergency- > > bounces@ietf.org] On Behalf Of Abbott, Nadine B. > > Sent: Thursday, October 28, 2004 9:48 AM > > To: James Winterbottom > > Cc: sipping-emergency@ietf.org > > Subject: RE: [Sipping-emergency] RE: draft requirements for ECRIT: draft- > > winterbottom-ecrit-locati on-s cope-req-00 > > > > Hi, James, > > Could I have a copy too? > > Thanks, > > Nadine > > > > -----Original Message----- > > From: sipping-emergency-bounces@ietf.org > > [mailto:sipping-emergency-bounces@ietf.org] On Behalf Of Tschofenig Hannes > > Sent: Thursday, October 28, 2004 5:26 AM > > To: James Winterbottom > > Cc: sipping-emergency@ietf.org > > Subject: [Sipping-emergency] RE: draft requirements for ECRIT: > > draft-winterbottom-ecrit-locati on-s cope-req-00 > > > > > > hi james, > > > > thanks for the draft. you might want to announce it at the > > sipping-emergency@ietf.org mailing list. > > > > ciao > > hannes > > > > > > > -----Original Message----- > > > From: James Winterbottom [mailto:winterb@nortelnetworks.com] > > > Sent: Montag, 18. Oktober 2004 16:14 > > > To: 'internet-drafts@ietf.org' > > > Cc: jon.peterson@neustar.biz; Tschofenig Hannes; Martin > > > Dawson; Martin Thomson > > > Subject: draft requirements for ECRIT: > > > draft-winterbottom-ecrit-location-s cope-req-00 > > > > > > Attached, please find a draft being submitted for discussion > > > in the ECRIT WG. > > > > > > Abstract > > > > > > Special kinds of services require user location > > > information to be authenticated and validated within a > > > specific operating domain. An example of such a service is > > > the emergency services network, where the location of a > > > caller is known with in the domain of the telephone network, > > > while the name or true identity of the caller is not > > > intrinsically known. This paper describes the entities and > > > key requirements necessary to provide such a service an > > > internet environment. > > > > > > Regards > > > James Winterbottom > > > winterb@nortelnetworks.com > > > 61-2-42-233038 > > > > > > <> > > > > > > > > > > _______________________________________________ > > Sipping-emergency mailing list > > Sipping-emergency@ietf.org > > https://www1.ietf.org/mailman/listinfo/sipping-emergency > > > > _______________________________________________ > > Sipping-emergency mailing list > > Sipping-emergency@ietf.org > > https://www1.ietf.org/mailman/listinfo/sipping-emergency > > > > > > >_______________________________________________ >Sipping-emergency mailing list >Sipping-emergency@ietf.org >https://www1.ietf.org/mailman/listinfo/sipping-emergency cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Thu Oct 28 22:34:59 2004 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 WAA24462 for ; Thu, 28 Oct 2004 22:34:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNMpg-0000I2-5t for sipping-emergency-web-archive@ietf.org; Thu, 28 Oct 2004 22:49:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNKEa-0004Jk-7t; Thu, 28 Oct 2004 20:03:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNItw-0006Zt-8i for sipping-emergency@megatron.ietf.org; Thu, 28 Oct 2004 18:37:49 -0400 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 SAA01300 for ; Thu, 28 Oct 2004 18:37:46 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNJ86-0000iC-2u for sipping-emergency@ietf.org; Thu, 28 Oct 2004 18:52:26 -0400 Received: from [128.59.16.206] (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i9SMbTMd025066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Oct 2004 18:37:30 -0400 (EDT) Message-ID: <418174A4.1040001@cs.columbia.edu> Date: Thu, 28 Oct 2004 18:37:24 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Sipping-emergency] New revision of proposed ECRIT charter References: <4.3.2.7.2.20041028105119.0282cea8@localhost> In-Reply-To: <4.3.2.7.2.20041028105119.0282cea8@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2004.10.28.2 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: "Abbott, Nadine B." , sipping-emergency@ietf.org, Tschofenig Hannes X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit >> however, as nadine >> mentioned there are additional fields: >> - Customer Name, >> - Class of Service--Residence, Business, Public, etc. >> - information about/from a VoIP/Communications Service Provider >> >> this information is not included in the pidf-lo. >> >> is this use case for saml you are often talking about? Note that these are closely related to the vCard elements (and other, similarly static, descriptors) referenced in the SIMPLE CPID document. It might be worthwhile to look at extending those, rather than creating something new from whole cloth. _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Fri Oct 29 01:17:34 2004 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 BAA09896 for ; Fri, 29 Oct 2004 01:17:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNPN2-0005Av-JC for sipping-emergency-web-archive@ietf.org; Fri, 29 Oct 2004 01:32:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNP6f-0004oM-HJ; Fri, 29 Oct 2004 01:15:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNOzB-0004a9-M3 for sipping-emergency@megatron.ietf.org; Fri, 29 Oct 2004 01:07:37 -0400 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 BAA09465 for ; Fri, 29 Oct 2004 01:07:36 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNPDL-0004zp-UY for sipping-emergency@ietf.org; Fri, 29 Oct 2004 01:22:19 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 28 Oct 2004 22:16:26 -0700 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i9T571LO006851 for ; Thu, 28 Oct 2004 22:07:01 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id WAA02349 for ; Thu, 28 Oct 2004 22:07:01 -0700 (PDT) Message-Id: <4.3.2.7.2.20041028235820.026ebae0@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 29 Oct 2004 00:07:00 -0500 To: sipping-emergency@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Sipping-emergency] Comment about Charter [no privacy?] X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a All In reading the charter for our new ECRIT BOF, I don't see mention of privacy concerns wrt the ability to track an endpoint based on some Loc Info Server (LIS) always knowing where that endpoint is (if nomadic or mobile), or tying a user(name) to a particular endpoint (regardless of what type it is). I thought privacy was agreed upon to be mentioned as a consideration? I know at least Jonathan and I brought it up, and I think I remember Jon agreeing to this consideration. We do not want to ignore the retention and distribution rules we so carefully built into the PIDF-LO cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Fri Oct 29 02:57:52 2004 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 CAA29998 for ; Fri, 29 Oct 2004 02:57:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNQw6-0006pT-RD for sipping-emergency-web-archive@ietf.org; Fri, 29 Oct 2004 03:12:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNQa4-0006hb-VY; Fri, 29 Oct 2004 02:49:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNQKN-00060g-T3 for sipping-emergency@megatron.ietf.org; Fri, 29 Oct 2004 02:33:35 -0400 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 CAA29030 for ; Fri, 29 Oct 2004 02:33:33 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNQYa-0006TD-74 for sipping-emergency@ietf.org; Fri, 29 Oct 2004 02:48:17 -0400 Received: from zctwc060.asiapac.nortel.com (zctwc060.asiapac.nortel.com [47.153.200.67]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9T6WxV22721; Fri, 29 Oct 2004 01:32:59 -0500 (CDT) Received: by zctwc060.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Oct 2004 16:32:09 +1000 Message-ID: From: "James Winterbottom" To: "James M. Polk" , sipping-emergency@ietf.org Subject: RE: [Sipping-emergency] Comment about Charter [no privacy?] Date: Fri, 29 Oct 2004 16:32:03 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0024971643==" Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e 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. --===============0024971643== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4BD81.008B99DA" 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_001_01C4BD81.008B99DA Content-Type: text/plain Hi James, Doesn't "draft-ietf-geopriv-pres-02" suggest that a location server/generator is able to transmit a location to a location recipient, be that the target itself, or someone else. I believe that this is also covered in RFC-3693 GeoPriv Requirements. In order to be able to transmit a location, one must first be able to determine it!!! For the purposes of transmitting location pseudonyms are also used, so I am not sure where the tying to a user name comes in. What was submitted by me is a set of requirements that the authors believe need to be satisfied in order to meet the needs of emergency service providers. There has been no discussion of not using or varying the existing GeoPriv rulesets. Cheers James -----Original Message----- From: sipping-emergency-bounces@ietf.org [mailto:sipping-emergency-bounces@ietf.org] Sent: Friday, 29 October 2004 3:07 PM To: sipping-emergency@ietf.org Subject: [Sipping-emergency] Comment about Charter [no privacy?] All In reading the charter for our new ECRIT BOF, I don't see mention of privacy concerns wrt the ability to track an endpoint based on some Loc Info Server (LIS) always knowing where that endpoint is (if nomadic or mobile), or tying a user(name) to a particular endpoint (regardless of what type it is). I thought privacy was agreed upon to be mentioned as a consideration? I know at least Jonathan and I brought it up, and I think I remember Jon agreeing to this consideration. We do not want to ignore the retention and distribution rules we so carefully built into the PIDF-LO cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency ------_=_NextPart_001_01C4BD81.008B99DA Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sipping-emergency] Comment about Charter [no = privacy?]

Hi James,

Doesn't "draft-ietf-geopriv-pres-02" = suggest that a location server/generator is able to transmit a location = to a location recipient, be that the target itself, or someone else. I = believe that this is also covered in RFC-3693 GeoPriv Requirements. In = order to be able to transmit a location, one must first be able to = determine it!!! For the purposes of transmitting location pseudonyms = are also used, so I am not sure where the tying to a user name comes = in.

What was submitted by me is a set of requirements = that the authors believe need to be satisfied in order to meet the = needs of emergency service providers. There has been no discussion of = not using or varying the existing GeoPriv rulesets.


Cheers
James
 

-----Original Message-----
From: sipping-emergency-bounces@ietf.org [mailto:sipping-emerge= ncy-bounces@ietf.org]
Sent: Friday, 29 October 2004 3:07 PM
To: sipping-emergency@ietf.org
Subject: [Sipping-emergency] Comment about Charter = [no privacy?]


All

In reading the charter for our new ECRIT BOF, I don't = see mention of
privacy concerns wrt the ability to track an = endpoint based on some Loc
Info Server (LIS) always knowing where that endpoint = is (if nomadic or
mobile), or tying a user(name) to a particular = endpoint (regardless of what
type it is).

I thought privacy was agreed upon to be mentioned as = a consideration?

I know at least Jonathan and I brought it up, and I = think I remember Jon
agreeing to this consideration.

We do not want to ignore the retention and = distribution rules we so
carefully built into the PIDF-LO

cheers,
James

          &nb= sp;           &nb= sp;         = *******************
          &nb= sp;      Truth is not to be argued... it is to = be presented


_______________________________________________
Sipping-emergency mailing list
Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergen= cy

------_=_NextPart_001_01C4BD81.008B99DA-- --===============0024971643== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency --===============0024971643==-- From sipping-emergency-bounces@ietf.org Fri Oct 29 04:43:34 2004 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 EAA08257 for ; Fri, 29 Oct 2004 04:43:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNSaR-0000x9-P1 for sipping-emergency-web-archive@ietf.org; Fri, 29 Oct 2004 04:58:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNRzs-0005gY-KQ; Fri, 29 Oct 2004 04:20:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNRoR-0004KY-6o for sipping-emergency@megatron.ietf.org; Fri, 29 Oct 2004 04:08:43 -0400 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 EAA05809 for ; Fri, 29 Oct 2004 04:08:40 -0400 (EDT) Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNS2f-0000FV-6w for sipping-emergency@ietf.org; Fri, 29 Oct 2004 04:23:25 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id i9T88cP6013363; Fri, 29 Oct 2004 10:08:38 +0200 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id i9T88bBO016338; Fri, 29 Oct 2004 10:08:37 +0200 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <4BVR79SQ>; Fri, 29 Oct 2004 10:08:37 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04686937@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'James M. Polk'" , sipping-emergency@ietf.org Subject: RE: [Sipping-emergency] Comment about Charter [no privacy?] Date: Fri, 29 Oct 2004 10:08:32 +0200 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: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 hi james, do we need to mention it in the charter? it is obvious that privacy issues need to be addressed since we inherit them with the location work from the geopriv working group. the same is true for security issues. ciao hannes > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Freitag, 29. Oktober 2004 07:07 > To: sipping-emergency@ietf.org > Subject: [Sipping-emergency] Comment about Charter [no privacy?] > > All > > In reading the charter for our new ECRIT BOF, I don't see > mention of privacy concerns wrt the ability to track an > endpoint based on some Loc Info Server (LIS) always knowing > where that endpoint is (if nomadic or mobile), or tying a > user(name) to a particular endpoint (regardless of what type it is). > > I thought privacy was agreed upon to be mentioned as a consideration? > > I know at least Jonathan and I brought it up, and I think I > remember Jon agreeing to this consideration. > > We do not want to ignore the retention and distribution rules > we so carefully built into the PIDF-LO > > cheers, > James > > ******************* > Truth is not to be argued... it is to be presented > > > _______________________________________________ > Sipping-emergency mailing list > Sipping-emergency@ietf.org > https://www1.ietf.org/mailman/listinfo/sipping-emergency > _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Fri Oct 29 04:49:16 2004 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 EAA08746 for ; Fri, 29 Oct 2004 04:49:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNSfx-000169-Gc for sipping-emergency-web-archive@ietf.org; Fri, 29 Oct 2004 05:04:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNSEB-0004l5-13; Fri, 29 Oct 2004 04:35:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNRu9-0001fn-0L for sipping-emergency@megatron.ietf.org; Fri, 29 Oct 2004 04:14:37 -0400 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 EAA06283 for ; Fri, 29 Oct 2004 04:14:35 -0400 (EDT) Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNS8N-0000NL-JY for sipping-emergency@ietf.org; Fri, 29 Oct 2004 04:29:20 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id i9T8EXfO010354; Fri, 29 Oct 2004 10:14:33 +0200 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id i9T8EVBO022215; Fri, 29 Oct 2004 10:14:32 +0200 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <4BVR79XS>; Fri, 29 Oct 2004 10:14:31 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04686938@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'James Winterbottom'" , "James M. Polk" , sipping-emergency@ietf.org Subject: RE: [Sipping-emergency] Comment about Charter [no privacy?] Date: Fri, 29 Oct 2004 10:14:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.6 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0739594684==" Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 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. --===============0739594684== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4BD8F.4EBF2820" 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_001_01C4BD8F.4EBF2820 Content-Type: text/plain hi james, every document will have to address both privacy and security considerations. the geopriv requirements draft gives a number of guidelines but more work is needed when you apply it to an actual using protocol (such as sip). the fact that you have pseudonyms is nice but still there are some places where user names show up. for example, end-to-end security mechanisms provide the recipient a way to authenticate you (and authorizate you based on your authenticated identity) but if you want to experience anonymity then the authorization functionality at the recipient is certainly more difficult. ciao hannes _____ From: James Winterbottom [mailto:winterb@nortelnetworks.com] Sent: Freitag, 29. Oktober 2004 08:32 To: James M. Polk; sipping-emergency@ietf.org Subject: RE: [Sipping-emergency] Comment about Charter [no privacy?] Hi James, Doesn't "draft-ietf-geopriv-pres-02" suggest that a location server/generator is able to transmit a location to a location recipient, be that the target itself, or someone else. I believe that this is also covered in RFC-3693 GeoPriv Requirements. In order to be able to transmit a location, one must first be able to determine it!!! For the purposes of transmitting location pseudonyms are also used, so I am not sure where the tying to a user name comes in. What was submitted by me is a set of requirements that the authors believe need to be satisfied in order to meet the needs of emergency service providers. There has been no discussion of not using or varying the existing GeoPriv rulesets. Cheers James -----Original Message----- From: sipping-emergency-bounces@ietf.org [mailto:sipping-emergency-bounces@ietf.org ] Sent: Friday, 29 October 2004 3:07 PM To: sipping-emergency@ietf.org Subject: [Sipping-emergency] Comment about Charter [no privacy?] All In reading the charter for our new ECRIT BOF, I don't see mention of privacy concerns wrt the ability to track an endpoint based on some Loc Info Server (LIS) always knowing where that endpoint is (if nomadic or mobile), or tying a user(name) to a particular endpoint (regardless of what type it is). I thought privacy was agreed upon to be mentioned as a consideration? I know at least Jonathan and I brought it up, and I think I remember Jon agreeing to this consideration. We do not want to ignore the retention and distribution rules we so carefully built into the PIDF-LO cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency ------_=_NextPart_001_01C4BD8F.4EBF2820 Content-Type: text/html RE: [Sipping-emergency] Comment about Charter [no privacy?]
hi james,
 
every document will have to address both privacy and security considerations. the geopriv requirements draft gives a number of guidelines but more work is needed when you apply it to an actual using protocol (such as sip). the fact that you have pseudonyms is nice but still there are some places where user names show up. for example, end-to-end security mechanisms provide the recipient a way to authenticate you (and authorizate you based on your authenticated identity) but if you want to experience anonymity then the authorization functionality at the recipient is certainly more difficult.
 
ciao
hannes
 

From: James Winterbottom [mailto:winterb@nortelnetworks.com]
Sent: Freitag, 29. Oktober 2004 08:32
To: James M. Polk; sipping-emergency@ietf.org
Subject: RE: [Sipping-emergency] Comment about Charter [no privacy?]

Hi James,

Doesn't "draft-ietf-geopriv-pres-02" suggest that a location server/generator is able to transmit a location to a location recipient, be that the target itself, or someone else. I believe that this is also covered in RFC-3693 GeoPriv Requirements. In order to be able to transmit a location, one must first be able to determine it!!! For the purposes of transmitting location pseudonyms are also used, so I am not sure where the tying to a user name comes in.

What was submitted by me is a set of requirements that the authors believe need to be satisfied in order to meet the needs of emergency service providers. There has been no discussion of not using or varying the existing GeoPriv rulesets.


Cheers
James
 

-----Original Message-----
From: sipping-emergency-bounces@ietf.org [mailto:sipping-emergency-bounces@ietf.org]
Sent: Friday, 29 October 2004 3:07 PM
To: sipping-emergency@ietf.org
Subject: [Sipping-emergency] Comment about Charter [no privacy?]


All

In reading the charter for our new ECRIT BOF, I don't see mention of
privacy concerns wrt the ability to track an endpoint based on some Loc
Info Server (LIS) always knowing where that endpoint is (if nomadic or
mobile), or tying a user(name) to a particular endpoint (regardless of what
type it is).

I thought privacy was agreed upon to be mentioned as a consideration?

I know at least Jonathan and I brought it up, and I think I remember Jon
agreeing to this consideration.

We do not want to ignore the retention and distribution rules we so
carefully built into the PIDF-LO

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented


_______________________________________________
Sipping-emergency mailing list
Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency

------_=_NextPart_001_01C4BD8F.4EBF2820-- --===============0739594684== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency --===============0739594684==-- From sipping-emergency-bounces@ietf.org Fri Oct 29 05:21:58 2004 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 FAA10765 for ; Fri, 29 Oct 2004 05:21:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNTBc-0001gJ-2r for sipping-emergency-web-archive@ietf.org; Fri, 29 Oct 2004 05:36:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNSS4-0005MH-J6; Fri, 29 Oct 2004 04:49:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNSFf-0006ES-3X for sipping-emergency@megatron.ietf.org; Fri, 29 Oct 2004 04:36:55 -0400 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 EAA07733 for ; Fri, 29 Oct 2004 04:36:49 -0400 (EDT) Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNSTu-0000pC-0g for sipping-emergency@ietf.org; Fri, 29 Oct 2004 04:51:34 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id i9T8ajfO029428; Fri, 29 Oct 2004 10:36:45 +0200 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id i9T8aiBP013626; Fri, 29 Oct 2004 10:36:45 +0200 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <4BVR7026>; Fri, 29 Oct 2004 10:36:44 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0468693E@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'James M. Polk'" , "Abbott, Nadine B." , "Peterson, Jon" Subject: RE: [Sipping-emergency] New revision of proposed ECRIT charter Date: Fri, 29 Oct 2004 10:36:33 +0200 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: 2beba50d0fcdeee5f091c59f204d4365 Cc: sipping-emergency@ietf.org X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab hi james, nadine, henning, henning pointed us to some work in the simple wg. maybe you, nadine, want to check whether the nena requirements match the currently offered functionality. james, i still think that this can be realized with traits (but as henning said, it might not be necessary). the main question is whether you want to provide the information by yourself or asserted by someone else. ciao hannes > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Donnerstag, 28. Oktober 2004 17:53 > To: Tschofenig Hannes; Abbott, Nadine B.; Peterson, Jon > Cc: sipping-emergency@ietf.org > Subject: RE: [Sipping-emergency] New revision of proposed > ECRIT charter > > At 11:20 AM 10/28/2004 +0200, Tschofenig Hannes wrote: > >hi james, > > > >some data items seem to be part of the pidf-lo work. > > each of items below are or are not part of the pidf-lo. No > other fields in a SIP message should carry them, therefore > this is part of the geopriv wg > > >however, as nadine > >mentioned there are additional fields: > >- Customer Name, > >- Class of Service--Residence, Business, Public, etc. > >- information about/from a VoIP/Communications Service Provider > > > >this information is not included in the pidf-lo. > > > >is this use case for saml you are often talking about? > > saml asserts a trait, which none of the above are, each above > is individual or personal, not a trait > > > >ciao > >hannes > > > > > -----Original Message----- > > > From: James M. Polk [mailto:jmpolk@cisco.com] > > > Sent: Donnerstag, 21. Oktober 2004 17:33 > > > To: Abbott, Nadine B.; Peterson, Jon > > > Cc: sipping-emergency@ietf.org > > > Subject: RE: [Sipping-emergency] New revision of proposed > > > ECRIT charter > > > > > > Isn't most of this an extension to the PIDF-LO effort in > > > Geopriv, and not part of ECRIT? > > > > > > The portion that I believe is part of SIP/PING would be the > > > addition of a body part by the VSP (in add the contact info > > > you want) - which has so far been frowned upon (to say the > > > least) in these WGs > > > > > > At 10:57 AM 10/21/2004 -0400, Abbott, Nadine B. wrote: > > > >Jon, > > > > > > > >In the North American National Emergency Number Association > > > (NENA) VoIP > > > >Location WG, we have been grappling with the problem of how > > > additional > > > >information relevant to an emergency call might be carried to the > > > emergency > > > >call taker. For example, this might include information > about the > > > caller > > > >(e.g., Customer Name, Class of Service--Residence, > Business, Public, > > > etc.) > > > >and information about/from a VoIP/Communications Service Provider > > > (e.g., > > > >contact information for that provider) that are relevant to an > > > emergency > > > >call. We are not yet ready (before this next meeting) > to provide a > > > list of > > > >proposed requirements. > > > >However, I wondered if you consider that the charter for > ECRIT, as > > > written, > > > >covers the issue of how such information--caller supplied and/or > > > service > > > >provider supplied--might be carried in SIP? > > > > > > > >Respectfully, > > > >Nadine Abbott > > > >NENA VoIP Location WG team leader > > > > > > > >_______________________________________________ > > > >Sipping-emergency mailing list > > > >Sipping-emergency@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/sipping-emergency > > > > > > > > > cheers, > > > James > > > > > > ******************* > > > Truth is not to be argued... it is to be > presented > > > > > > > > > _______________________________________________ > > > Sipping-emergency mailing list > > > Sipping-emergency@ietf.org > > > https://www1.ietf.org/mailman/listinfo/sipping-emergency > > > > > > cheers, > James > > ******************* > Truth is not to be argued... it is to be presented > > > _______________________________________________ > Sipping-emergency mailing list > Sipping-emergency@ietf.org > https://www1.ietf.org/mailman/listinfo/sipping-emergency > _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Fri Oct 29 08:39:12 2004 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 IAA24566 for ; Fri, 29 Oct 2004 08:39:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNWGQ-0005tp-V7 for sipping-emergency-web-archive@ietf.org; Fri, 29 Oct 2004 08:53:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNVat-0001pA-Eu; Fri, 29 Oct 2004 08:10:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNVYN-0006Sz-G8 for sipping-emergency@megatron.ietf.org; Fri, 29 Oct 2004 08:08:24 -0400 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 IAA22088 for ; Fri, 29 Oct 2004 08:08:21 -0400 (EDT) Message-Id: <200410291208.IAA22088@ietf.org> Received: from winwebhosting.com ([67.15.20.8] helo=dx24.winwebhosting.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNVmT-0005Aq-Kd for sipping-emergency@ietf.org; Fri, 29 Oct 2004 08:23:08 -0400 Received: from acs-24-154-127-195.zoominternet.net ([24.154.127.195] helo=BROSENLT) by dx24.winwebhosting.com with esmtpa (Exim 4.43) id 1CNVXD-0003F1-22; Fri, 29 Oct 2004 07:07:12 -0500 From: "Brian Rosen" To: "'Tschofenig Hannes'" , "'James Winterbottom'" , "'James M. Polk'" , Subject: RE: [Sipping-emergency] Comment about Charter [no privacy?] Date: Fri, 29 Oct 2004 08:07:18 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcS9lCLO93tu8LpkQieTy+U0iRWBzQAF+TZA In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F04686938@mchp905a.mch.sbs.de> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx24.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.6 (/) X-Scan-Signature: b4c10eaa27436d806c79842272125a2a X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1098094847==" Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 1.3 (+) X-Scan-Signature: c6c6a408c8e09c950064e70d807ac007 This is a multi-part message in MIME format. --===============1098094847== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0FC3_01C4BD8E.50D887B0" This is a multi-part message in MIME format. ------=_NextPart_000_0FC3_01C4BD8E.50D887B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is a good point. This points out a common tension between groups seeking authenticity and groups seeking privacy. The emergency call authorities reasonably want to prevent forging of location, which could be used to direct responders away from something bad about to happen. Individuals do not want their location to be able to be tracked in some circumstances. In North America, the tension between privacy and location authenticity is solved with legislation: the privacy right is explicitly waived when an emergency call is placed. It would be interesting to know if this is not the case in other areas. This is a geopriv issue, but we might have to send some requirements to them over the issue. Recognize that automatic reporting of location is implemented because all too often the caller does not know where they are, or is unable to communicate where they are, to the call taker. When you make an emergency call, you MUST provide location, and in every jurisdiction, it would be a crime to falsely report your location. I would think that given the history in geopriv over this issue, that we aren't going to get IETF to publish an RFC where not reporting location is incompliant with a spec; we have a sufficient number of people who feel passionately that an individual cannot be COMPELLED to report location. This is quite easily dealt with by using SHOULD language. The emergency call system can choose to accept such calls or not, as local regulations dictate. The most straightforward method of providing authentication would be to have the location object signed by a trusted entity. I've had a running dialog with James Winterbottom and his co-authors on this subject; I maintain it is not practical to always have a trusted entity, but let's say, for this discussion, that there is. If only the location object itself is signed, and no other identifying piece of information that attaches an identity to the location, then you can assure that the location report itself has not been modified, but you don't know that the object represents the location of the entity presenting it (you are subject to a replay attack). The only way to be assured that the location object represents the entity presenting it would be to have a credential or other identifier in the signed object that was verifiable by the entity receiving the call as belonging to the entity placing the call. I have no idea what such a credential/identifier could be because, as I will show, the entity that could reasonably sign the LO doesn't have any identity for the entity placing the call when it has to sign the object; they are entirely disconnected from one another. This thread is about how to make sure that whatever identifier is used, it can't be used to specifically identify a person. That still doesn't solve the problems of what entities could reasonably assert location validation, and how any form of anonymous, but authenticated, location could be provided. I have no suggestions. Brian _____ From: sipping-emergency-bounces@ietf.org [mailto:sipping-emergency-bounces@ietf.org] On Behalf Of Tschofenig Hannes Sent: Friday, October 29, 2004 4:14 AM To: 'James Winterbottom'; James M. Polk; sipping-emergency@ietf.org Subject: RE: [Sipping-emergency] Comment about Charter [no privacy?] hi james, every document will have to address both privacy and security considerations. the geopriv requirements draft gives a number of guidelines but more work is needed when you apply it to an actual using protocol (such as sip). the fact that you have pseudonyms is nice but still there are some places where user names show up. for example, end-to-end security mechanisms provide the recipient a way to authenticate you (and authorizate you based on your authenticated identity) but if you want to experience anonymity then the authorization functionality at the recipient is certainly more difficult. ciao hannes _____ From: James Winterbottom [mailto:winterb@nortelnetworks.com] Sent: Freitag, 29. Oktober 2004 08:32 To: James M. Polk; sipping-emergency@ietf.org Subject: RE: [Sipping-emergency] Comment about Charter [no privacy?] Hi James, Doesn't "draft-ietf-geopriv-pres-02" suggest that a location server/generator is able to transmit a location to a location recipient, be that the target itself, or someone else. I believe that this is also covered in RFC-3693 GeoPriv Requirements. In order to be able to transmit a location, one must first be able to determine it!!! For the purposes of transmitting location pseudonyms are also used, so I am not sure where the tying to a user name comes in. What was submitted by me is a set of requirements that the authors believe need to be satisfied in order to meet the needs of emergency service providers. There has been no discussion of not using or varying the existing GeoPriv rulesets. Cheers James -----Original Message----- From: sipping-emergency-bounces@ietf.org [mailto:sipping-emergency-bounces@ietf.org] Sent: Friday, 29 October 2004 3:07 PM To: sipping-emergency@ietf.org Subject: [Sipping-emergency] Comment about Charter [no privacy?] All In reading the charter for our new ECRIT BOF, I don't see mention of privacy concerns wrt the ability to track an endpoint based on some Loc Info Server (LIS) always knowing where that endpoint is (if nomadic or mobile), or tying a user(name) to a particular endpoint (regardless of what type it is). I thought privacy was agreed upon to be mentioned as a consideration? I know at least Jonathan and I brought it up, and I think I remember Jon agreeing to this consideration. We do not want to ignore the retention and distribution rules we so carefully built into the PIDF-LO cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency ------=_NextPart_000_0FC3_01C4BD8E.50D887B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Sipping-emergency] Comment about Charter [no = privacy?]

This is a good = point.

 

This points out a common tension = between groups seeking authenticity and groups seeking = privacy.

 

The emergency call authorities = reasonably want to prevent forging of location, which could be used to direct = responders away from something bad about to happen.  Individuals do not want = their location to be able to be tracked in some circumstances.  =  

 

In North = America, the tension between privacy and location authenticity is solved with legislation: the privacy right is explicitly waived when an emergency = call is placed.  It would be interesting to know if this is not the case in = other areas.  This is a geopriv issue, but we might have to send some requirements to them over the issue.

 

Recognize that automatic reporting = of location is implemented because all too often the caller does not know = where they are, or is unable to communicate where they are, to the call taker. =   When you make an emergency call, you MUST provide location, and in every jurisdiction, it would be a crime to falsely report your = location.

 

I would think that given the = history in geopriv over this issue, that we aren’t going to get IETF to = publish an RFC where not reporting location is incompliant with a spec; we have a sufficient number of people who feel passionately that an individual = cannot be COMPELLED to report location.  This is quite easily dealt with by = using SHOULD language.  The emergency call system can choose to accept = such calls or not, as local regulations dictate.  =

 

The most straightforward method of providing authentication would be to have the location object signed by = a trusted entity.  I’ve had a running dialog with James = Winterbottom and his co-authors on this subject; I maintain it is not practical to always = have a trusted entity, but let’s say, for this discussion, that there = is.  If only the location object itself is signed, and no other identifying = piece of information that attaches an identity to the location, then you can = assure that the location report itself has not been modified, but you don’t = know that the object represents the location of the entity presenting it (you are = subject to a replay attack).   The only way to be assured that the = location object represents the entity presenting it would be to have a credential = or other identifier in the signed object that was verifiable by the entity = receiving the call as belonging to the entity placing the call.  I have no = idea what such a credential/identifier could be because, as I will show, the = entity that could reasonably sign the LO doesn’t have any identity for the = entity placing the call when it has to sign the object; they are entirely = disconnected from one another.  This thread is about how to make sure that = whatever identifier is used, it can’t be used to specifically identify a = person.  That still doesn’t solve the problems of what entities could = reasonably assert location validation, and how any form of anonymous, but = authenticated, location could be provided.  I have no = suggestions.

 

Brian

 

From: sipping-emergency-bounces@ietf.org = [mailto:sipping-emergency-bounces@ietf.org] On Behalf Of Tschofenig Hannes
Sent: Friday, October 29, = 2004 4:14 AM
To: 'James Winterbottom'; = James M. Polk; sipping-emergency@ietf.org
Subject: RE: = [Sipping-emergency] Comment about Charter [no privacy?]

 

hi james, =

 

every document will have to address = both privacy and security considerations. the geopriv requirements draft = gives a number of guidelines but more work is needed when you apply it to = an actual using protocol (such as sip). the fact that you have = pseudonyms is nice but still there are some places where user names show up. for = example, end-to-end security mechanisms provide the recipient a way to = authenticate you (and authorizate you based on your authenticated identity) but if you = want to experience anonymity then the authorization functionality at the recipient is certainly more difficult. =

 

ciao

hannes

 

 

From: James Winterbottom [mailto:winterb@nortelnetworks.com]
Sent: Freitag, 29. = Oktober 2004 08:32
To: James M. Polk; sipping-emergency@ietf.org
Subject: RE: = [Sipping-emergency] Comment about Charter [no privacy?]

Hi James,

Doesn't "draft-ietf-geopriv-pres-02" suggest that a location = server/generator is able to transmit a location to a location recipient, be that the = target itself, or someone else. I believe that this is also covered in RFC-3693 GeoPriv Requirements. In order to be able to transmit a location, one = must first be able to determine it!!! For the purposes of transmitting = location pseudonyms are also used, so I am not sure where the tying to a user = name comes in.

What was submitted by me is a set of requirements that the authors believe need = to be satisfied in order to meet the needs of emergency service providers. = There has been no discussion of not using or varying the existing GeoPriv = rulesets.

 

Cheers
James
  =

-----Original Message-----
From: sipping-emergency-bounces@ietf.org [mailto:sipping-emergen= cy-bounces@ietf.org]
Sent: Friday, 29 October = 2004 3:07 PM
To: = sipping-emergency@ietf.org
Subject: = [Sipping-emergency] Comment about Charter [no privacy?]

 

All

In reading the charter for our new ECRIT BOF, I don't see mention of =
privacy concerns wrt the = ability to track an endpoint based on some Loc
Info Server (LIS) always = knowing where that endpoint is (if nomadic or
mobile), or tying a = user(name) to a particular endpoint (regardless of what
type it = is).

I thought privacy was agreed upon to be mentioned as a = consideration?

I know at least Jonathan and I brought it up, and I think I remember Jon =
agreeing to this = consideration.

We do not want to ignore the retention and distribution rules we so =
carefully built into the = PIDF-LO

cheers,
James =

       &nbs= p;            = ;            *******************
       &nbs= p;         Truth is not to be argued... it is to be presented =

 

______________________________________________= _
Sipping-emergency = mailing list
Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergenc= y

------=_NextPart_000_0FC3_01C4BD8E.50D887B0-- --===============1098094847== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency --===============1098094847==-- From sipping-emergency-bounces@ietf.org Fri Oct 29 09:03:06 2004 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 JAA26606 for ; Fri, 29 Oct 2004 09:03:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNWdd-0006UN-3g for sipping-emergency-web-archive@ietf.org; Fri, 29 Oct 2004 09:17:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNWID-0000wS-BE; Fri, 29 Oct 2004 08:55:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNWAG-0003bv-HY for sipping-emergency@megatron.ietf.org; Fri, 29 Oct 2004 08:47:32 -0400 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 IAA25327 for ; Fri, 29 Oct 2004 08:47:31 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNWOX-00066n-5f for sipping-emergency@ietf.org; Fri, 29 Oct 2004 09:02:18 -0400 Received: from razor.cs.columbia.edu (IDENT:f7wK6sC/2kWzdoZGERCliq2y4Qf4F2LK@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i9TCkERX014857; Fri, 29 Oct 2004 08:46:14 -0400 (EDT) Received: from [127.0.0.1] (IDENT:EyiQ4l4Nl1DuNHNbAMmahahLOFH39k6W@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i9TCk9XH006687; Fri, 29 Oct 2004 08:46:10 -0400 Message-ID: <41823B32.80606@cs.columbia.edu> Date: Fri, 29 Oct 2004 08:44:34 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tschofenig Hannes Subject: Re: [Sipping-emergency] New revision of proposed ECRIT charter References: <2A8DB02E3018D411901B009027FD3A3F0468693E@mchp905a.mch.sbs.de> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F0468693E@mchp905a.mch.sbs.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2004.10.29.0 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: "'James M. Polk'" , sipping-emergency@ietf.org, "Abbott, Nadine B." X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Tschofenig Hannes wrote: > hi james, nadine, henning, > > henning pointed us to some work in the simple wg. maybe you, nadine, want to > check whether the nena requirements match the currently offered > functionality. To amplify: vCard currently provides the name (and other information), but doesn't provide the service provider name and other details. However, it would seem trivial to add either to CIPID or vCard, as they may well be useful outside the emergency services context. From a data type perspective, these pieces of information aren't really location information, so stuffing them into PIDF-LO or an extension thereof seems a bit of a stretch. My general inclination is to avoid emergency-only protocol features. Henning _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Fri Oct 29 09:27:26 2004 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 JAA27921 for ; Fri, 29 Oct 2004 09:27:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNX1C-0006uZ-2M for sipping-emergency-web-archive@ietf.org; Fri, 29 Oct 2004 09:42:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNWhW-0007Jw-6C; Fri, 29 Oct 2004 09:21:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNWV0-00085C-J9 for sipping-emergency@megatron.ietf.org; Fri, 29 Oct 2004 09:08:58 -0400 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 JAA26943 for ; Fri, 29 Oct 2004 09:08:57 -0400 (EDT) Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNWjI-0006ad-2J for sipping-emergency@ietf.org; Fri, 29 Oct 2004 09:23:44 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id i9TD8ofO015350; Fri, 29 Oct 2004 15:08:50 +0200 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id i9TD8nBO013506; Fri, 29 Oct 2004 15:08:49 +0200 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <4BVR8FQ5>; Fri, 29 Oct 2004 15:08:49 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04686949@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Brian Rosen'" , "'James Winterbottom'" , "'James M. Polk'" , sipping-emergency@ietf.org Subject: RE: [Sipping-emergency] Comment about Charter [no privacy?] Date: Fri, 29 Oct 2004 15:08:39 +0200 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: 850245b51c39701e2700a112f3032caa X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 # hi brian, # thanks for raising these issues. please see my comments inline: From: Brian Rosen [mailto:br@brianrosen.net] Sent: Freitag, 29. Oktober 2004 14:07 To: Tschofenig Hannes; 'James Winterbottom'; 'James M. Polk'; sipping-emergency@ietf.org Subject: RE: [Sipping-emergency] Comment about Charter [no privacy?] This is a good point. This points out a common tension between groups seeking authenticity and groups seeking privacy. # i fully agree with you that there is always different entities with different requirements (which are, unfortunately, often conflicting). The emergency call authorities reasonably want to prevent forging of location, which could be used to direct responders away from something bad about to happen. Individuals do not want their location to be able to be tracked in some circumstances. # i guess that the threat model is a bit more complicated (just some preliminary thoughts): you need to worry about - the end host (which might not always be trustworthy) - intermediate sip proxies - the emergency center - entities providing the location information (e.g., dhcp server, some nodes in the network, etc.) - entities which just observe the communication (e.g., on a wireless link) - entities which can actively participate in the communication (as a mitm adversary) In North America, the tension between privacy and location authenticity is solved with legislation: the privacy right is explicitly waived when an emergency call is placed. It would be interesting to know if this is not the case in other areas. This is a geopriv issue, but we might have to send some requirements to them over the issue. # the geopriv working group will be pleased to see the requirements but the requirements document has been finalized some time ago. if there are new requirements which lead to new protocol mechanisms (which i am not sure) then they new work needs to be started. at the moment i, however, think that the individual building blocks just need to be combined in a useful fashion. Recognize that automatic reporting of location is implemented because all too often the caller does not know where they are, or is unable to communicate where they are, to the call taker. When you make an emergency call, you MUST provide location, and in every jurisdiction, it would be a crime to falsely report your location. # true. that's even true today but too often some folks do not care about this issue. one way to limit this problem is to verify (or add location information) by the outbound proxy. this, however, has its own limitations, as you know. I would think that given the history in geopriv over this issue, that we aren't going to get IETF to publish an RFC where not reporting location is incompliant with a spec; we have a sufficient number of people who feel passionately that an individual cannot be COMPELLED to report location. This is quite easily dealt with by using SHOULD language. The emergency call system can choose to accept such calls or not, as local regulations dictate. The most straightforward method of providing authentication would be to have the location object signed by a trusted entity. I've had a running dialog with James Winterbottom and his co-authors on this subject; I maintain it is not practical to always have a trusted entity, but let's say, for this discussion, that there is. If only the location object itself is signed, and no other identifying piece of information that attaches an identity to the location, then you can assure that the location report itself has not been modified, but you don't know that the object represents the location of the entity presenting it (you are subject to a replay attack). The only way to be assured that the location object represents the entity presenting it would be to have a credential or other identifier in the signed object that was verifiable by the entity receiving the call as belonging to the entity placing the call. I have no idea what such a credential/identifier could be because, as I will show, the entity that could reasonably sign the LO doesn't have any identity for the entity placing the call when it has to sign the object; they are entirely disconnected from one another. This thread is about how to make sure that whatever identifier is used, it can't be used to specifically identify a person. That still doesn't solve the problems of what entities could reasonably assert location validation, and how any form of anonymous, but authenticated, location could be provided. I have no suggestions. # digitally signing the location object does not prevent replay attacks. that's for sure. however, in combination with some other mechanisms i think that a deployable system can be developed. as an example, if you have a location object which is not signed by the end host itself but rather by a different entity then you can combine it with sip specific security mechanisms (such as s/mime protection) to indicate to the emergency center that you placed the call. in any case you need to differentiate between the case where the end host generated the location object and a case where this is done by a third party (for example because the end host does not know its own location information). the location object needs to indicate the target identity and this information is provided by pidf-lo: " The GEOPRIV requirements [10] (or REQ for short) specify the need for a name for the person, place or thing that location information describes (REQ 2.1). PIDF has such an identifier already, since every PIDF document has an "entity" attribute of the 'presence' element that signifies the URI of the entity whose presence the document describes. " (section 2.1 of http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pidf-lo-03.txt) i think that these different aspects will be written down somewhere. (maybe they are already covered by some of the drafts.) ciao hannes Brian ________________________________ From: sipping-emergency-bounces@ietf.org [mailto:sipping-emergency-bounces@ietf.org] On Behalf Of Tschofenig Hannes Sent: Friday, October 29, 2004 4:14 AM To: 'James Winterbottom'; James M. Polk; sipping-emergency@ietf.org Subject: RE: [Sipping-emergency] Comment about Charter [no privacy?] hi james, every document will have to address both privacy and security considerations. the geopriv requirements draft gives a number of guidelines but more work is needed when you apply it to an actual using protocol (such as sip). the fact that you have pseudonyms is nice but still there are some places where user names show up. for example, end-to-end security mechanisms provide the recipient a way to authenticate you (and authorizate you based on your authenticated identity) but if you want to experience anonymity then the authorization functionality at the recipient is certainly more difficult. ciao hannes ________________________________ From: James Winterbottom [mailto:winterb@nortelnetworks.com] Sent: Freitag, 29. Oktober 2004 08:32 To: James M. Polk; sipping-emergency@ietf.org Subject: RE: [Sipping-emergency] Comment about Charter [no privacy?] Hi James, Doesn't "draft-ietf-geopriv-pres-02" suggest that a location server/generator is able to transmit a location to a location recipient, be that the target itself, or someone else. I believe that this is also covered in RFC-3693 GeoPriv Requirements. In order to be able to transmit a location, one must first be able to determine it!!! For the purposes of transmitting location pseudonyms are also used, so I am not sure where the tying to a user name comes in. What was submitted by me is a set of requirements that the authors believe need to be satisfied in order to meet the needs of emergency service providers. There has been no discussion of not using or varying the existing GeoPriv rulesets. Cheers James -----Original Message----- From: sipping-emergency-bounces@ietf.org [mailto:sipping-emergency-bounces@ietf.org] Sent: Friday, 29 October 2004 3:07 PM To: sipping-emergency@ietf.org Subject: [Sipping-emergency] Comment about Charter [no privacy?] All In reading the charter for our new ECRIT BOF, I don't see mention of privacy concerns wrt the ability to track an endpoint based on some Loc Info Server (LIS) always knowing where that endpoint is (if nomadic or mobile), or tying a user(name) to a particular endpoint (regardless of what type it is). I thought privacy was agreed upon to be mentioned as a consideration? I know at least Jonathan and I brought it up, and I think I remember Jon agreeing to this consideration. We do not want to ignore the retention and distribution rules we so carefully built into the PIDF-LO cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Fri Oct 29 09:58:24 2004 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 JAA00736 for ; Fri, 29 Oct 2004 09:58:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNXVA-0007gO-DJ for sipping-emergency-web-archive@ietf.org; Fri, 29 Oct 2004 10: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 1CNX4r-0002FA-KK; Fri, 29 Oct 2004 09:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNWkt-0008BW-B9 for sipping-emergency@megatron.ietf.org; Fri, 29 Oct 2004 09:25:23 -0400 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 JAA27842 for ; Fri, 29 Oct 2004 09:25:21 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNWzA-0006sp-TB for sipping-emergency@ietf.org; Fri, 29 Oct 2004 09:40:09 -0400 Received: from razor.cs.columbia.edu (IDENT:6mc5FF81K7VbCSe5n/JAfoomfO3YiWLI@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i9TDOxRX021774; Fri, 29 Oct 2004 09:25:00 -0400 (EDT) Received: from [127.0.0.1] (IDENT:rpjv+HT5SShSFGym7k8M0SymoMrHzcAX@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i9TDOwXH006868; Fri, 29 Oct 2004 09:24:58 -0400 Message-ID: <41824442.1010609@cs.columbia.edu> Date: Fri, 29 Oct 2004 09:23:14 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Sipping-emergency] Comment about Charter [no privacy?] References: <200410291208.IAA22088@ietf.org> In-Reply-To: <200410291208.IAA22088@ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2004.10.29.0 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by cs.columbia.edu id i9TDOxRX021774 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable Cc: "'James M. Polk'" , sipping-emergency@ietf.org, "'Tschofenig Hannes'" X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable Brian Rosen wrote: > I would think that given the history in geopriv over this issue, that w= e=20 > aren=92t going to get IETF to publish an RFC where not reporting locati= on=20 > is incompliant with a spec; we have a sufficient number of people who=20 > feel passionately that an individual cannot be COMPELLED to report=20 > location. This is quite easily dealt with by using SHOULD language. =20 > The emergency call system can choose to accept such calls or not, as=20 > local regulations dictate.=20 It's a bit more complicated than that, as there are at least three=20 reasons not to provide location: (1) The calling end system (and elements along the call path) may not=20 know the location; this is obviously going to be quite common,=20 particularly in the early days. Having the PSAP refuse all such calls=20 seems unwise. (2) The caller may refuse to give his location for good or bad reasons. (3) The caller may not be at the scene of the emergency or may report a=20 non-emergency-related issue and have a legitimate interest not to report=20 his location or identity. (I suspect quite a few crime tips are phoned=20 into 911, even though they might not be emergencies as such.) I don't think we need to deal with (3). A PSAP could simply tell the=20 caller that the call location is recorded and provide an anonymous tip=20 line number. I don't think including "sorry, I wish I could provide my location, but=20 I can't" is particularly useful since bad guys will have little=20 compunction about fibbing. In addition, "providing location" is not binary. I might decide or be=20 able to provide location sufficient to route the call (e.g., town=20 level), but not to dispatch a fire engine (house level). I'm not sure what to do about this. In classical 911, this is easy since=20 the system can compel you to provide location. In practice, I don't think this is as big a problem. People routinely=20 call 911 from payphones or non-phase-II cell phones today, where even=20 knowing the location doesn't exactly help you to find malicious callers. The best we can probably do is to provide degrees of assurance so that=20 the responder can better tell if he should be suspicious of the call and=20 maybe question the caller a bit more. ("What's the name of the cross=20 street? How come it's dead quiet in the background when you're on=20 Broadway and 42nd street?") >=20 > =20 >=20 > The most straightforward method of providing authentication would be to= =20 > have the location object signed by a trusted entity. I=92ve had a runn= ing=20 > dialog with James Winterbottom and his co-authors on this subject; I=20 > maintain it is not practical to always have a trusted entity, but let=92= s=20 > say, for this discussion, that there is. If only the location object=20 > itself is signed, and no other identifying piece of information that=20 > attaches an identity to the location, then you can assure that the=20 > location report itself has not been modified, but you don=92t know that= =20 > the object represents the location of the entity presenting it (you are= =20 > subject to a replay attack). The only way to be assured that the=20 > location object represents the entity presenting it would be to have a=20 > credential or other identifier in the signed object that was verifiable= =20 > by the entity receiving the call as belonging to the entity placing the= =20 > call. I have no idea what such a credential/identifier could be=20 > because, as I will show, the entity that could reasonably sign the LO=20 > doesn=92t have any identity for the entity placing the call when it has= to=20 > sign the object; they are entirely disconnected from one another. This= =20 > thread is about how to make sure that whatever identifier is used, it=20 > can=92t be used to specifically identify a person. That still doesn=92= t=20 > solve the problems of what entities could reasonably assert location=20 > validation, and how any form of anonymous, but authenticated, location=20 > could be provided. I have no suggestions. >=20 > =20 >=20 > Brian _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Fri Oct 29 12:28:47 2004 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 MAA13024 for ; Fri, 29 Oct 2004 12:28:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNZqj-0002gf-Ec for sipping-emergency-web-archive@ietf.org; Fri, 29 Oct 2004 12:43:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNZE4-0000MX-LW; Fri, 29 Oct 2004 12:03:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNZ3d-0002me-Gt for sipping-emergency@megatron.ietf.org; Fri, 29 Oct 2004 11:52:53 -0400 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 LAA10714 for ; Fri, 29 Oct 2004 11:52:50 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNZHv-0001yZ-DV for sipping-emergency@ietf.org; Fri, 29 Oct 2004 12:07:40 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 29 Oct 2004 09:04:06 -0700 X-BrightmailFiltered: true Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9TFqFQ0017618; Fri, 29 Oct 2004 08:52:15 -0700 (PDT) Received: from mlinsnerzk7abh (ssh-sjc-1.cisco.com [171.68.225.134]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA17428; Fri, 29 Oct 2004 08:52:15 -0700 (PDT) From: "Marc Linsner" To: "'Brian Rosen'" , Subject: RE: [Sipping-emergency] Comment about Charter [no privacy?] Date: Fri, 29 Oct 2004 11:52:14 -0400 Message-ID: <001101c4bdcf$43c80b40$210d0d0a@mlinsnerzk7abh> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <200410291208.IAA22088@ietf.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Spam-Score: 1.4 (+) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0014460330==" Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 1.5 (+) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f This is a multi-part message in MIME format. --===============0014460330== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01C4BDAD.BCB66B40" This is a multi-part message in MIME format. ------=_NextPart_000_0012_01C4BDAD.BCB66B40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit in-line.... -----Original Message----- From: sipping-emergency-bounces@ietf.org [mailto:sipping-emergency-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Friday, October 29, 2004 8:07 AM To: 'Tschofenig Hannes'; 'James Winterbottom'; 'James M. Polk'; sipping-emergency@ietf.org Subject: RE: [Sipping-emergency] Comment about Charter [no privacy?] This is a good point. This points out a common tension between groups seeking authenticity and groups seeking privacy. The emergency call authorities reasonably want to prevent forging of location, which could be used to direct responders away from something bad about to happen. Individuals do not want their location to be able to be tracked in some circumstances. In North America, the tension between privacy and location authenticity is solved with legislation: the privacy right is explicitly waived when an emergency call is placed. This is only partially true, there are states that allow a user to request that no ALI record is created for their phone number. (Just want to make sure we spin it correctly!) -Marc Linsner- ------=_NextPart_000_0012_01C4BDAD.BCB66B40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
in-line....
-----Original Message-----
From:=20 sipping-emergency-bounces@ietf.org = [mailto:sipping-emergency-bounces@ietf.org]=20 On Behalf Of Brian Rosen
Sent: Friday, October 29, = 2004 8:07=20 AM
To: 'Tschofenig Hannes'; 'James Winterbottom'; 'James M. = Polk';=20 sipping-emergency@ietf.org
Subject: RE: [Sipping-emergency] = Comment=20 about Charter [no privacy?]

This is a = good=20 point.

 

This points = out a=20 common tension between groups seeking authenticity and groups seeking=20 privacy.

 

The = emergency call=20 authorities reasonably want to prevent forging of location, which = could be=20 used to direct responders away from something bad about to happen.=20  Individuals do not want their location to be able to be tracked = in some=20 circumstances.   

 

In = North America, the tension between privacy and = location=20 authenticity is solved with legislation: the privacy right is = explicitly=20 waived when an emergency call is placed.   

 

This is only partially true, there are = states that=20 allow a user to request that no ALI record is created for their phone=20 number.  (Just want to make sure we spin it=20 correctly!)

 

-Marc = Linsner-

------=_NextPart_000_0012_01C4BDAD.BCB66B40-- --===============0014460330== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency --===============0014460330==-- From sipping-emergency-bounces@ietf.org Fri Oct 29 13:36:17 2004 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 NAA18044 for ; Fri, 29 Oct 2004 13:36:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNau5-0004By-0l for sipping-emergency-web-archive@ietf.org; Fri, 29 Oct 2004 13:51:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNaZe-0000kD-0h; Fri, 29 Oct 2004 13:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNaO7-00035R-Mg for sipping-emergency@megatron.ietf.org; Fri, 29 Oct 2004 13:18:10 -0400 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 NAA16850 for ; Fri, 29 Oct 2004 13:18:04 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNacO-0003oY-F0 for sipping-emergency@ietf.org; Fri, 29 Oct 2004 13:32:55 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 29 Oct 2004 10:27:02 -0700 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9THHRQ0014339; Fri, 29 Oct 2004 10:17:28 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA23314; Fri, 29 Oct 2004 10:17:28 -0700 (PDT) Message-Id: <4.3.2.7.2.20041029120929.0264bee8@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 29 Oct 2004 12:17:30 -0500 To: Henning Schulzrinne , Tschofenig Hannes From: "James M. Polk" Subject: Re: [Sipping-emergency] New revision of proposed ECRIT charter In-Reply-To: <41823B32.80606@cs.columbia.edu> References: <2A8DB02E3018D411901B009027FD3A3F0468693E@mchp905a.mch.sbs.de> <2A8DB02E3018D411901B009027FD3A3F0468693E@mchp905a.mch.sbs.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sipping-emergency@ietf.org, "Abbott, Nadine B." X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 What Nadine wants is the name of the organization that provided the location to the endpoint. This is not a decoupled action between the CIPID and the PIDF-LO, their are in association with each other. Revealing who asserts my location information (Fort_worth_VPC.org) reveals fairly specifically where I am in most contexts. This is a revelation of location information I as a user might not want in my location policy. If you mandate it is outside of the rules of PIDF-LO, we must generate a duplicate set of privacy and security requirements in this WG At 08:44 AM 10/29/2004 -0400, Henning Schulzrinne wrote: >Tschofenig Hannes wrote: >>hi james, nadine, henning, >>henning pointed us to some work in the simple wg. maybe you, nadine, want to >>check whether the nena requirements match the currently offered >>functionality. > >To amplify: vCard currently provides the name (and other information), but >doesn't provide the service provider name and other details. However, it >would seem trivial to add either to CIPID or vCard, as they may well be >useful outside the emergency services context. From a data type >perspective, these pieces of information aren't really location >information, so stuffing them into PIDF-LO or an extension thereof seems a >bit of a stretch. > >My general inclination is to avoid emergency-only protocol features. > >Henning > > cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Fri Oct 29 13:36:25 2004 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 NAA18085 for ; Fri, 29 Oct 2004 13:36:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNauC-0004CG-SF for sipping-emergency-web-archive@ietf.org; Fri, 29 Oct 2004 13:51:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNaZf-0000nb-EX; Fri, 29 Oct 2004 13:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNaPV-0003s6-Fh for sipping-emergency@megatron.ietf.org; Fri, 29 Oct 2004 13:19:33 -0400 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 NAA16938 for ; Fri, 29 Oct 2004 13:19:30 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNadp-0003qJ-8p for sipping-emergency@ietf.org; Fri, 29 Oct 2004 13:34:21 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 29 Oct 2004 10:28:30 -0700 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9THIawu013900; Fri, 29 Oct 2004 10:18:37 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA26088; Fri, 29 Oct 2004 10:18:58 -0700 (PDT) Message-Id: <4.3.2.7.2.20041029115721.02869ad8@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 29 Oct 2004 12:05:23 -0500 To: "James Winterbottom" , sipping-emergency@ietf.org From: "James M. Polk" Subject: RE: [Sipping-emergency] Comment about Charter [no privacy?] In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc James First of all, I was referring specifically to the text in the Charter - not your document that hasn't been published yet. Speaking of which - what was submitted by you? Hadn't Brian even determined you didn't submit your document on time - therefore no one in the IETF is aware of it? I know I cannot find it in IETF announcements list. I'd like to review it, truly. But I don't have access to it. I don't know in what you reference pseudonyms At 04:32 PM 10/29/2004 +1000, James Winterbottom wrote: >Hi James, > >Doesn't "draft-ietf-geopriv-pres-02" suggest that a location >server/generator is able to transmit a location to a location recipient, >be that the target itself, or someone else. I believe that this is also >covered in RFC-3693 GeoPriv Requirements. In order to be able to transmit >a location, one must first be able to determine it!!! For the purposes of >transmitting location pseudonyms are also used, so I am not sure where the >tying to a user name comes in. > >What was submitted by me is a set of requirements that the authors believe >need to be satisfied in order to meet the needs of emergency service >providers. There has been no discussion of not using or varying the >existing GeoPriv rulesets. > >Cheers >James > > >-----Original Message----- >From: sipping-emergency-bounces@ietf.org >[mailto:sipping-emergency-bounces@ietf.org] > >Sent: Friday, 29 October 2004 3:07 PM >To: sipping-emergency@ietf.org >Subject: [Sipping-emergency] Comment about Charter [no privacy?] > >All > >In reading the charter for our new ECRIT BOF, I don't see mention of >privacy concerns wrt the ability to track an endpoint based on some Loc >Info Server (LIS) always knowing where that endpoint is (if nomadic or >mobile), or tying a user(name) to a particular endpoint (regardless of what >type it is). > >I thought privacy was agreed upon to be mentioned as a consideration? > >I know at least Jonathan and I brought it up, and I think I remember Jon >agreeing to this consideration. > >We do not want to ignore the retention and distribution rules we so >carefully built into the PIDF-LO > >cheers, >James > > ******************* > Truth is not to be argued... it is to be presented > >_______________________________________________ >Sipping-emergency mailing list >Sipping-emergency@ietf.org >https://www1.ietf.org/mailman/listinfo/sipping-emergency > cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Fri Oct 29 13:40:22 2004 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 NAA18324 for ; Fri, 29 Oct 2004 13:40:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNaxz-0004Gd-PV for sipping-emergency-web-archive@ietf.org; Fri, 29 Oct 2004 13:55:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNaf3-0006ay-5t; Fri, 29 Oct 2004 13:35:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNaYQ-0008W3-7g for sipping-emergency@megatron.ietf.org; Fri, 29 Oct 2004 13:28:46 -0400 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 NAA17594 for ; Fri, 29 Oct 2004 13:28:43 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNamg-000415-Rc for sipping-emergency@ietf.org; Fri, 29 Oct 2004 13:43:34 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 29 Oct 2004 10:39:31 -0700 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9THRgQ0021543; Fri, 29 Oct 2004 10:27:42 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA11934; Fri, 29 Oct 2004 10:27:41 -0700 (PDT) Message-Id: <4.3.2.7.2.20041029122059.02762bf8@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 29 Oct 2004 12:27:42 -0500 To: "Brian Rosen" , "'Tschofenig Hannes'" , "'James Winterbottom'" , From: "James M. Polk" Subject: RE: [Sipping-emergency] Comment about Charter [no privacy?] In-Reply-To: <3hr0l2$7q69t@sj-inbound-c.cisco.com> References: <2A8DB02E3018D411901B009027FD3A3F04686938@mchp905a.mch.sbs.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 If all documents have to address privacy and security in compliance to that which was specifically addressed in Geopriv, and these two topics were already discussed on this list for inclusion in the charter, then why not agree to add the text? At 08:07 AM 10/29/2004 -0400, Brian Rosen wrote: >This is a good point. > >This points out a common tension between groups seeking authenticity and >groups seeking privacy. > >The emergency call authorities reasonably want to prevent forging of >location, which could be used to direct responders away from something bad >about to happen. Individuals do not want their location to be able to be >tracked in some circumstances. > >In North America, the tension between privacy and location authenticity is >solved with legislation: the privacy right is explicitly waived when an >emergency call is placed. It would be interesting to know if this is not >the case in other areas. This is a geopriv issue, but we might have to >send some requirements to them over the issue. > >Recognize that automatic reporting of location is implemented because all >too often the caller does not know where they are, or is unable to >communicate where they are, to the call taker. When you make an >emergency call, you MUST provide location, and in every jurisdiction, it >would be a crime to falsely report your location. > >I would think that given the history in geopriv over this issue, that we >aren t going to get IETF to publish an RFC where not reporting location is >incompliant with a spec; we have a sufficient number of people who feel >passionately that an individual cannot be COMPELLED to report >location. This is quite easily dealt with by using SHOULD language. The >emergency call system can choose to accept such calls or not, as local >regulations dictate. > >The most straightforward method of providing authentication would be to >have the location object signed by a trusted entity. I ve had a running >dialog with James Winterbottom and his co-authors on this subject; I >maintain it is not practical to always have a trusted entity, but let s >say, for this discussion, that there is. If only the location object >itself is signed, and no other identifying piece of information that >attaches an identity to the location, then you can assure that the >location report itself has not been modified, but you don t know that the >object represents the location of the entity presenting it (you are >subject to a replay attack). The only way to be assured that the >location object represents the entity presenting it would be to have a >credential or other identifier in the signed object that was verifiable by >the entity receiving the call as belonging to the entity placing the >call. I have no idea what such a credential/identifier could be because, >as I will show, the entity that could reasonably sign the LO doesn t have >any identity for the entity placing the call when it has to sign the >object; they are entirely disconnected from one another. This thread is >about how to make sure that whatever identifier is used, it can t be used >to specifically identify a person. That still doesn t solve the problems >of what entities could reasonably assert location validation, and how any >form of anonymous, but authenticated, location could be provided. I have >no suggestions. > > > >Brian > > > >---------- >From: sipping-emergency-bounces@ietf.org >[mailto:sipping-emergency-bounces@ietf.org] On Behalf Of Tschofenig Hannes >Sent: Friday, October 29, 2004 4:14 AM >To: 'James Winterbottom'; James M. Polk; sipping-emergency@ietf.org >Subject: RE: [Sipping-emergency] Comment about Charter [no privacy?] > > > >hi james, > > > >every document will have to address both privacy and security >considerations. the geopriv requirements draft gives a number of >guidelines but more work is needed when you apply it to an actual using >protocol (such as sip). the fact that you have pseudonyms is nice but >still there are some places where user names show up. for example, >end-to-end security mechanisms provide the recipient a way to authenticate >you (and authorizate you based on your authenticated identity) but if you >want to experience anonymity then the authorization functionality at the >recipient is certainly more difficult. > > > >ciao > >hannes > > > >---------- >From: James Winterbottom [mailto:winterb@nortelnetworks.com] >Sent: Freitag, 29. Oktober 2004 08:32 >To: James M. Polk; sipping-emergency@ietf.org >Subject: RE: [Sipping-emergency] Comment about Charter [no privacy?] >Hi James, > >Doesn't "draft-ietf-geopriv-pres-02" suggest that a location >server/generator is able to transmit a location to a location recipient, >be that the target itself, or someone else. I believe that this is also >covered in RFC-3693 GeoPriv Requirements. In order to be able to transmit >a location, one must first be able to determine it!!! For the purposes of >transmitting location pseudonyms are also used, so I am not sure where the >tying to a user name comes in. >What was submitted by me is a set of requirements that the authors believe >need to be satisfied in order to meet the needs of emergency service >providers. There has been no discussion of not using or varying the >existing GeoPriv rulesets. > > >Cheers >James > > >-----Original Message----- >From: sipping-emergency-bounces@ietf.org >[mailto:sipping-emergency-bounces@ietf.org] > >Sent: Friday, 29 October 2004 3:07 PM >To: sipping-emergency@ietf.org >Subject: [Sipping-emergency] Comment about Charter [no privacy?] > > > >All > >In reading the charter for our new ECRIT BOF, I don't see mention of >privacy concerns wrt the ability to track an endpoint based on some Loc >Info Server (LIS) always knowing where that endpoint is (if nomadic or >mobile), or tying a user(name) to a particular endpoint (regardless of what >type it is). > >I thought privacy was agreed upon to be mentioned as a consideration? > >I know at least Jonathan and I brought it up, and I think I remember Jon >agreeing to this consideration. > >We do not want to ignore the retention and distribution rules we so >carefully built into the PIDF-LO > >cheers, >James > > ******************* > Truth is not to be argued... it is to be presented > > > >_______________________________________________ >Sipping-emergency mailing list >Sipping-emergency@ietf.org >https://www1.ietf.org/mailman/listinfo/sipping-emergency > cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Fri Oct 29 13:56:25 2004 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 NAA19545 for ; Fri, 29 Oct 2004 13:56:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNbDH-0004de-OG for sipping-emergency-web-archive@ietf.org; Fri, 29 Oct 2004 14:11:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNauA-00006B-Jf; Fri, 29 Oct 2004 13:51:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNamS-0002Yq-T8 for sipping-emergency@megatron.ietf.org; Fri, 29 Oct 2004 13:43:16 -0400 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 NAA18575 for ; Fri, 29 Oct 2004 13:43:15 -0400 (EDT) Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNb0h-0004LU-VC for sipping-emergency@ietf.org; Fri, 29 Oct 2004 13:58:05 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id i9THh2BO014109; Fri, 29 Oct 2004 19:43:02 +0200 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id i9THh2BO011087; Fri, 29 Oct 2004 19:43:02 +0200 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <4BVR8KM2>; Fri, 29 Oct 2004 19:43:02 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04686955@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'James M. Polk'" , Brian Rosen , "'James Winterbottom'" , sipping-emergency@ietf.org Date: Fri, 29 Oct 2004 19:42:53 +0200 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: bb8eae9af85e4fcfe76f325e38493bf4 Subject: [Sipping-emergency] (no subject) X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Fri Oct 29 17:18:01 2004 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 RAA13583 for ; Fri, 29 Oct 2004 17:18:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNeMf-0002Ut-Eo for sipping-emergency-web-archive@ietf.org; Fri, 29 Oct 2004 17:32:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNdhx-0003fC-UZ; Fri, 29 Oct 2004 16:50:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNd1W-0002mq-EU for sipping-emergency@megatron.ietf.org; Fri, 29 Oct 2004 16:07:02 -0400 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 QAA01722 for ; Fri, 29 Oct 2004 16:06:55 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNdFq-0007gN-Cx for sipping-emergency@ietf.org; Fri, 29 Oct 2004 16:21:47 -0400 Received: from [128.59.16.206] (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i9TK5hMd001802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 29 Oct 2004 16:05:44 -0400 (EDT) Message-ID: <4182A292.3020902@cs.columbia.edu> Date: Fri, 29 Oct 2004 16:05:38 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Sipping-emergency] New revision of proposed ECRIT charter References: <2A8DB02E3018D411901B009027FD3A3F0468693E@mchp905a.mch.sbs.de> <2A8DB02E3018D411901B009027FD3A3F0468693E@mchp905a.mch.sbs.de> <4.3.2.7.2.20041029120929.0264bee8@localhost> In-Reply-To: <4.3.2.7.2.20041029120929.0264bee8@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2004.10.29.1 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: "Abbott, Nadine B." , sipping-emergency@ietf.org, Tschofenig Hannes X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit That makes sense to me. If this is just meta-date for the location, it should be closely tied to that data. James M. Polk wrote: > What Nadine wants is the name of the organization that provided the > location to the endpoint. This is not a decoupled action between the > CIPID and the PIDF-LO, their are in association with each other. > Revealing who asserts my location information (Fort_worth_VPC.org) > reveals fairly specifically where I am in most contexts. This is a > revelation of location information I as a user might not want in my > location policy. If you mandate it is outside of the rules of PIDF-LO, > we must generate a duplicate set of privacy and security requirements in > this WG _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency