From mailman-bounces@ietf.org Mon Nov 1 09:01: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 JAA04266 for ; Mon, 1 Nov 2004 09:01:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COczJ-0007kA-N0 for sipping-emergency-web-archive@ietf.org; Mon, 01 Nov 2004 09:16:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COZkj-0001EO-6z for sipping-emergency-web-archive@ietf.org; Mon, 01 Nov 2004 05:49:33 -0500 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: Mon, 01 Nov 2004 05:19:23 -0500 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 Nov 1 12:20:55 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 MAA05669 for ; Mon, 1 Nov 2004 12:20:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COg6Q-0004om-PQ for sipping-emergency-web-archive@ietf.org; Mon, 01 Nov 2004 12:36:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COfWP-0004Hz-8X; Mon, 01 Nov 2004 11:59:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COf4c-0007d8-QX for sipping-emergency@megatron.ietf.org; Mon, 01 Nov 2004 11:30:26 -0500 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 LAA29166 for ; Mon, 1 Nov 2004 11:30:25 -0500 (EST) 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 1COfJX-0003AH-Tz for sipping-emergency@ietf.org; Mon, 01 Nov 2004 11:45:53 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 01 Nov 2004 08:39:58 -0800 Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iA1GTinC005329 for ; Mon, 1 Nov 2004 08:29:44 -0800 (PST) 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 IAA02023 for ; Mon, 1 Nov 2004 08:29:49 -0800 (PST) From: "Marc Linsner" To: Date: Mon, 1 Nov 2004 11:29:47 -0500 Message-ID: <00e501c4c030$024c8930$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: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Subject: [Sipping-emergency] ECRIT on Friday? 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: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Is this final?? Just want to be sure... -Marc Linsner- _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Mon Nov 1 13:43: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 NAA16791 for ; Mon, 1 Nov 2004 13:43:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COhOf-0007zz-7t for sipping-emergency-web-archive@ietf.org; Mon, 01 Nov 2004 13:59:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COgoe-0007da-Vb; Mon, 01 Nov 2004 13:22:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COgUN-0003ku-A9 for sipping-emergency@megatron.ietf.org; Mon, 01 Nov 2004 13:01:07 -0500 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 NAA10280 for ; Mon, 1 Nov 2004 13:01:05 -0500 (EST) 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 1COgjJ-000611-7g for sipping-emergency@ietf.org; Mon, 01 Nov 2004 13:16:34 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 01 Nov 2004 10:10:39 -0800 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 iA1H0Wcp019275; Mon, 1 Nov 2004 09:00:32 -0800 (PST) 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 KAA10259; Mon, 1 Nov 2004 10:00:31 -0800 (PST) Message-Id: <4.3.2.7.2.20041101115754.034b4ea8@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 01 Nov 2004 12:00:34 -0500 To: "Marc Linsner" , From: "James M. Polk" Subject: Re: [Sipping-emergency] ECRIT on Friday? In-Reply-To: <00e501c4c030$024c8930$210d0d0a@mlinsnerzk7abh> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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: 97adf591118a232206bdb5a27b217034 At 11:29 AM 11/1/2004 -0500, Marc Linsner wrote: >Is this final?? I thought I remembered reading in one official email that the final agenda was to be sent out by 10/29 - but it is still listed as a "Draft" at: http://www.ietf.org/meetings/agenda_61.html and I believe there are still at least 2 other WGs that are attempting to move slots >Just want to be sure... > > >-Marc Linsner- > > >_______________________________________________ >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 Mon Nov 1 14:44:55 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 OAA21942 for ; Mon, 1 Nov 2004 14:44:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COiLp-0000y6-UQ for sipping-emergency-web-archive@ietf.org; Mon, 01 Nov 2004 15:00:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COhu8-0004AQ-PR; Mon, 01 Nov 2004 14:31:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COhe9-0005E4-RO for sipping-emergency@megatron.ietf.org; Mon, 01 Nov 2004 14:15:18 -0500 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 OAA19199 for ; Mon, 1 Nov 2004 14:15:15 -0500 (EST) Received: from dnsmx2pya.telcordia.com ([128.96.20.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COht6-0000EX-Df for sipping-emergency@ietf.org; Mon, 01 Nov 2004 14:30:45 -0500 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 iA1JEJg06985; Mon, 1 Nov 2004 14:14:20 -0500 (EST) 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 M2004110114141712674 ; Mon, 01 Nov 2004 14:14:17 -0500 Received: by rrc-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2657.72) id <409CTZV7>; Mon, 1 Nov 2004 14:14:17 -0500 Message-ID: From: "Abbott, Nadine B." To: "'James M. Polk'" , Henning Schulzrinne , Tschofenig Hannes Subject: RE: [Sipping-emergency] New revision of proposed ECRIT charter Date: Mon, 1 Nov 2004 14:14:15 -0500 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: b4a0a5f5992e2a4954405484e7717d8c 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: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 James, I think that the name/contact info of the provider of the location object is already, appropriately, included in the PIDF-LO. My original question was posed to try to determine the appropriate forum to address additional information that might be provided by either the caller, or possibly with the assistance of a VoIP Service Provider, if one exists, on emergency calls. This is not information that would logically or necessarily be known to a provider of a location object. It is conceivable that such information might be included as extensions to the PIDF-LO in order to take advantage of the work already done to protect privacy by geopriv. However, it is also possible that such information might be included in a separate object which would could have different privacy needs. For example, it might not need to be made available to intermediaries (because it's not needed for routing), but could be made available only to the receiving emergency call center. This object could possibly leverage the work on privacy and security requirements done by geopriv? I was trying to understand what WG would consider that within scope. Thanks, Nadine -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com] Sent: Friday, October 29, 2004 1:18 PM To: Henning Schulzrinne; Tschofenig Hannes Cc: Abbott, Nadine B.; Peterson, Jon; sipping-emergency@ietf.org Subject: Re: [Sipping-emergency] New revision of proposed ECRIT charter 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 Mon Nov 1 16:51: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 QAA08116 for ; Mon, 1 Nov 2004 16:51:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COkK0-00050r-Rf for sipping-emergency-web-archive@ietf.org; Mon, 01 Nov 2004 17:06:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COj1k-0005a1-EZ; Mon, 01 Nov 2004 15:43:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COiiY-00083B-FK for sipping-emergency@megatron.ietf.org; Mon, 01 Nov 2004 15:23:54 -0500 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 PAA26838 for ; Mon, 1 Nov 2004 15:23:51 -0500 (EST) Received: from [209.108.197.61] (helo=ns1.sccx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COixK-0001vb-9R for sipping-emergency@ietf.org; Mon, 01 Nov 2004 15:39:23 -0500 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] Comment about Charter [no privacy?] X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 1 Nov 2004 14:22:46 -0600 Message-ID: <422D410BD61FC04185076AD99AA7207A69D042@inilmx01.lgmt.trdo> Thread-Topic: [Sipping-emergency] Comment about Charter [no privacy?] Thread-Index: AcS9v1/8xKKPemNmTZWsFwg8FkoHLwCdRqwQ From: "McCalmont, Patti" To: "Henning Schulzrinne" X-OriginalArrivalTime: 01 Nov 2004 20:22:53.0183 (UTC) FILETIME=[90C2F8F0:01C4C050] X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 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: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: quoted-printable A couple of comments, in line. Patti McCalmont -----Original Message----- From: sipping-emergency-bounces@ietf.org [mailto:sipping-emergency-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Friday, October 29, 2004 8:23 AM To: Brian Rosen Cc: 'James M. Polk'; sipping-emergency@ietf.org; 'Tschofenig Hannes' Subject: Re: [Sipping-emergency] Comment about Charter [no privacy?] Brian Rosen wrote: > I would think that given the history in geopriv over this issue, that=20 > we aren't going to get IETF to publish an RFC where not reporting=20 > location is incompliant with a spec; we have a sufficient number of=20 > 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=20 > local regulations dictate. It's a bit more complicated than that, as there are at least three reasons not to provide location: (1) The calling end system (and elements along the call path) may not know the location; this is obviously going to be quite common, particularly in the early days. Having the PSAP refuse all such calls seems unwise. There needs to be location provided by some source to enable a PSAP to assist with the emergency request. Developing systems without the ability to provide location for an emergency call is unwise. (2) The caller may refuse to give his location for good or bad reasons. In North America, this is not allowed. An area that supports E911 has all their callers in the ALI database (yes, there can be errors but there is a process to correct these). No one can opt out. A solution that compromises the current North American level of service would not be acceptable. (3) The caller may not be at the scene of the emergency or may report a non-emergency-related issue and have a legitimate interest not to report his location or identity. (I suspect quite a few crime tips are phoned into 911, even though they might not be emergencies as such.) dialing 9-1-1 provides location so a user doesn't get a choice. I don't think we need to deal with (3). A PSAP could simply tell the caller that the call location is recorded and provide an anonymous tip line number. I don't think including "sorry, I wish I could provide my location, but I can't" is particularly useful since bad guys will have little compunction about fibbing. Agreed. That's why location must be validated and delivered to the PSAP in conjunction with the call. In addition, "providing location" is not binary. I might decide or be able to provide location sufficient to route the call (e.g., town 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 the system can compel you to provide location. In practice, I don't think this is as big a problem. People routinely call 911 from payphones or non-phase-II cell phones today, where even knowing the location doesn't exactly help you to find malicious callers. But it can help, especially if there is an officer near the location when the PSAP receives the prank call. The best we can probably do is to provide degrees of assurance so that the responder can better tell if he should be suspicious of the call and maybe question the caller a bit more. ("What's the name of the cross street? How come it's dead quiet in the background when you're on Broadway and 42nd street?") Better to provide information within the record delivered to the PSAP on the "assurance" of the caller's location rather than needing to train all PSAPs to be more suspicious because the signaling interface has changed. Patti >=20 > =20 >=20 > The most straightforward method of providing authentication would be=20 > to have the location object signed by a trusted entity. I've had a=20 > running dialog with James Winterbottom and his co-authors on this=20 > subject; I maintain it is not practical to always have a trusted=20 > entity, but let's say, for this discussion, that there is. If only=20 > the location object itself is signed, and no other identifying piece=20 > of information that attaches an identity to the location, then you can > assure that the location report itself has not been modified, but you=20 > 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=20 > location object represents the entity presenting it would be to have a > credential or other identifier in the signed object that was=20 > verifiable by the entity receiving the call as belonging to the entity > placing the call. I have no idea what such a credential/identifier=20 > could be because, as I will show, the entity that could reasonably=20 > sign the LO doesn't have any identity for the entity placing the call=20 > when it has to sign the object; they are entirely disconnected from=20 > one another. This thread is about how to make sure that whatever=20 > identifier is used, it can't be used to specifically identify a=20 > person. That still doesn't solve the problems of what entities could=20 > reasonably assert location validation, and how any form of anonymous,=20 > but authenticated, location 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 _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Mon Nov 1 18:01:33 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 SAA16656 for ; Mon, 1 Nov 2004 18:01:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COlQ8-0007Yj-R2 for sipping-emergency-web-archive@ietf.org; Mon, 01 Nov 2004 18:17:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COkj1-0005EZ-3t; Mon, 01 Nov 2004 17:32:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COkSp-0003rN-3C for sipping-emergency@megatron.ietf.org; Mon, 01 Nov 2004 17:15:47 -0500 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 RAA11495 for ; Mon, 1 Nov 2004 17:15:45 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COkhn-00060l-T9 for sipping-emergency@ietf.org; Mon, 01 Nov 2004 17:31:16 -0500 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 iA1MEif24309; Mon, 1 Nov 2004 16:14:45 -0600 (CST) Received: by zctwc060.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Nov 2004 09:14:44 +1100 Message-ID: From: "James Winterbottom" To: "McCalmont, Patti" , Henning Schulzrinne Subject: RE: [Sipping-emergency] Comment about Charter [no privacy?] Date: Tue, 2 Nov 2004 09:14:36 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: cd000eda3d43531d5b01b5d305410e3c 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: , Content-Type: multipart/mixed; boundary="===============0973114233==" Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4ec3642ae9025e273a4a263d640f3300 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. --===============0973114233== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C060.2BEF1F02" 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_01C4C060.2BEF1F02 Content-Type: text/plain Location today is required for call routing and emergency dispatch and so for the charter to be useful, it needs to satisfy the requirements of its users who in this case are largely the emergency service providers. -----Original Message----- From: sipping-emergency-bounces@ietf.org [mailto:sipping-emergency-bounces@ietf.org] Sent: Tuesday, 2 November 2004 7:23 AM To: Henning Schulzrinne Cc: sipping-emergency@ietf.org Subject: RE: [Sipping-emergency] Comment about Charter [no privacy?] A couple of comments, in line. Patti McCalmont -----Original Message----- From: sipping-emergency-bounces@ietf.org [mailto:sipping-emergency-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Friday, October 29, 2004 8:23 AM To: Brian Rosen Cc: 'James M. Polk'; sipping-emergency@ietf.org; 'Tschofenig Hannes' Subject: Re: [Sipping-emergency] Comment about Charter [no privacy?] Brian Rosen wrote: > 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. It's a bit more complicated than that, as there are at least three reasons not to provide location: (1) The calling end system (and elements along the call path) may not know the location; this is obviously going to be quite common, particularly in the early days. Having the PSAP refuse all such calls seems unwise. There needs to be location provided by some source to enable a PSAP to assist with the emergency request. Developing systems without the ability to provide location for an emergency call is unwise. (2) The caller may refuse to give his location for good or bad reasons. In North America, this is not allowed. An area that supports E911 has all their callers in the ALI database (yes, there can be errors but there is a process to correct these). No one can opt out. A solution that compromises the current North American level of service would not be acceptable. (3) The caller may not be at the scene of the emergency or may report a non-emergency-related issue and have a legitimate interest not to report his location or identity. (I suspect quite a few crime tips are phoned into 911, even though they might not be emergencies as such.) dialing 9-1-1 provides location so a user doesn't get a choice. I don't think we need to deal with (3). A PSAP could simply tell the caller that the call location is recorded and provide an anonymous tip line number. I don't think including "sorry, I wish I could provide my location, but I can't" is particularly useful since bad guys will have little compunction about fibbing. Agreed. That's why location must be validated and delivered to the PSAP in conjunction with the call. In addition, "providing location" is not binary. I might decide or be able to provide location sufficient to route the call (e.g., town 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 the system can compel you to provide location. In practice, I don't think this is as big a problem. People routinely call 911 from payphones or non-phase-II cell phones today, where even knowing the location doesn't exactly help you to find malicious callers. But it can help, especially if there is an officer near the location when the PSAP receives the prank call. The best we can probably do is to provide degrees of assurance so that the responder can better tell if he should be suspicious of the call and maybe question the caller a bit more. ("What's the name of the cross street? How come it's dead quiet in the background when you're on Broadway and 42nd street?") Better to provide information within the record delivered to the PSAP on the "assurance" of the caller's location rather than needing to train all PSAPs to be more suspicious because the signaling interface has changed. Patti > > > > 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 _______________________________________________ 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 ------_=_NextPart_001_01C4C060.2BEF1F02 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sipping-emergency] Comment about Charter [no = privacy?]

Location today is required for call routing and = emergency dispatch and so for the charter to be useful, it needs to = satisfy the requirements of its users who in this case are largely the = emergency service providers.





-----Original Message-----
From: sipping-emergency-bounces@ietf.org [mailto:sipping-emerge= ncy-bounces@ietf.org]
Sent: Tuesday, 2 November 2004 7:23 AM
To: Henning Schulzrinne
Cc: sipping-emergency@ietf.org
Subject: RE: [Sipping-emergency] Comment about = Charter [no privacy?]


 A couple of comments, in line.

Patti McCalmont

-----Original Message-----
From: sipping-emergency-bounces@ietf.org
[mailto:sipping-emerge= ncy-bounces@ietf.org] On Behalf Of Henning Schulzrinne
Sent: Friday, October 29, 2004 8:23 AM
To: Brian Rosen
Cc: 'James M. Polk'; sipping-emergency@ietf.org; = 'Tschofenig Hannes'
Subject: Re: [Sipping-emergency] Comment about = Charter [no privacy?]

Brian Rosen wrote:

> 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.

It's a bit more complicated than that, as there are = at least three reasons not to provide location:

(1) The calling end system (and elements along the = call path) may not know the location; this is obviously going to be = quite common, particularly in the early days. Having the PSAP refuse = all such calls seems unwise.

<PLM> There needs to be location provided by = some source to enable a PSAP to assist with the emergency request. = Developing systems without the ability to provide location for an = emergency call is unwise.

(2) The caller may refuse to give his location for = good or bad reasons.

<PLM> In North America, this is not allowed. An = area that supports E911 has all their callers in the ALI database (yes, = there can be errors but there is a process to correct these). No one = can opt out. A solution that compromises the current North American = level of service would not be acceptable.

(3) The caller may not be at the scene of the = emergency or may report a non-emergency-related issue and have a = legitimate interest not to report his location or identity. (I suspect = quite a few crime tips are phoned into 911, even though they might not = be emergencies as such.)

<PLM> dialing 9-1-1 provides location so a user = doesn't get a choice.

I don't think we need to deal with (3). A PSAP could = simply tell the caller that the call location is recorded and provide = an anonymous tip line number.

I don't think including "sorry, I wish I could = provide my location, but I can't" is particularly useful since bad = guys will have little compunction about fibbing.

<PLM> Agreed. That's why location must be = validated and delivered to the PSAP in conjunction with the = call.

In addition, "providing location" is not = binary. I might decide or be able to provide location sufficient to = route the call (e.g., town 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 the system can compel you to provide = location.

In practice, I don't think this is as big a problem. = People routinely call 911 from payphones or non-phase-II cell phones = today, where even knowing the location doesn't exactly help you to find = malicious callers.

<PLM> But it can help, especially if there is = an officer near the location when the PSAP receives the prank = call.

The best we can probably do is to provide degrees of = assurance so that the responder can better tell if he should be = suspicious of the call and maybe question the caller a bit more. = ("What's the name of the cross street? How come it's dead quiet in = the background when you're on Broadway and 42nd = street?")

<PLM> Better to provide information within the = record delivered to the PSAP on the "assurance" of the = caller's location rather than needing to train all PSAPs to be more = suspicious because the signaling interface has changed.

Patti

>
> 
>
> 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

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

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

------_=_NextPart_001_01C4C060.2BEF1F02-- --===============0973114233== 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 --===============0973114233==-- From sipping-emergency-bounces@ietf.org Wed Nov 10 14:42: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 OAA18210 for ; Wed, 10 Nov 2004 14:42:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRyN7-000380-No for sipping-emergency-web-archive@ietf.org; Wed, 10 Nov 2004 14:43:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRyJ5-0007nY-IW; Wed, 10 Nov 2004 14:39:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRyHp-0007PB-5v for sipping-emergency@megatron.ietf.org; Wed, 10 Nov 2004 14:37:45 -0500 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 OAA17858 for ; Wed, 10 Nov 2004 14:37:43 -0500 (EST) Received: from bay21-f11.bay21.hotmail.com ([65.54.233.100] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRyIp-00030Z-4H for sipping-emergency@ietf.org; Wed, 10 Nov 2004 14:38:48 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 10 Nov 2004 11:37:02 -0800 Received: from 130.129.135.53 by by21fd.bay21.hotmail.msn.com with HTTP; Wed, 10 Nov 2004 19:36:47 GMT X-Originating-IP: [130.129.135.53] X-Originating-Email: [hannestschofenig@hotmail.com] X-Sender: hannestschofenig@hotmail.com From: "Hannes Tschofenig" To: sipping-emergency@ietf.org Date: Wed, 10 Nov 2004 20:36:47 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Message-ID: X-OriginalArrivalTime: 10 Nov 2004 19:37:02.0687 (UTC) FILETIME=[A70E56F0:01C4C75C] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA17858 Subject: [Sipping-emergency] ecrit agenda 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: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable hi all, attached you find our agenda proposal: --------------- FRIDAY, November 12, 2004 0900-1130 Morning Sessions Agenda/Charter Jon Peterson, Hannes Tschofenig (15 min) Requirements for Session Initiation Protocol (SIP)-based Emergency Calls Henning Schulzrinne (10 min) http://www.cs.columbia.edu/sip/draft/emergency-req/draft-schulzrinne-sipp= ing-emergency-req-01.html Emergency Services for Internet Telephony Systems Henning Schulzrinne (10 min) http://www.cs.columbia.edu/sip/draft/emergency-arch/draft-schulzrinne-sip= ping-emergency-arch-02.html Problem space in North America and current architecture Brian Rosen (10 min) Design considerations for ECRIT Ted Hardie (20 min) Open Discussions All (15 min) --------------- we are looking forward to see some interesting discussions. ciao hannes _________________________________________________________________ Wenn=92s mal schnell gehen soll. MSN Suche. http://search.msn.de/ Jetzt=20 kostenlos nutzen und keine Zeit mehr verlieren. _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency