From ecrit-bounces@ietf.org Tue Oct 04 09:08:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMmXJ-0007ul-F6; Tue, 04 Oct 2005 09:08:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMmXH-0007ug-17 for ecrit@megatron.ietf.org; Tue, 04 Oct 2005 09:08:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16745 for ; Tue, 4 Oct 2005 09:08:45 -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.43) id 1EMmfu-0008Sb-4G for ecrit@ietf.org; Tue, 04 Oct 2005 09:17:45 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 04 Oct 2005 06:08:32 -0700 X-IronPort-AV: i="3.97,172,1125903600"; d="scan'208"; a="663328740:sNHT24478068" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j94D8B4r008818 for ; Tue, 4 Oct 2005 06:08:30 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Oct 2005 06:08:25 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Oct 2005 06:08:25 -0700 From: "Marc Linsner" To: "'ECRIT'" Date: Tue, 4 Oct 2005 09:08:23 -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: AcXI5LInXtWD0OvfSHC9TvRV23M/eA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-OriginalArrivalTime: 04 Oct 2005 13:08:25.0551 (UTC) FILETIME=[B473BDF0:01C5C8E4] X-Spam-Score: 1.1 (+) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Subject: [Ecrit] Pre-Call (time) Routing (PCR) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The subject of routing an emergency call prior to the time of actual call-setup execution was pointed out during the discussion of draft-polk-dhc-uri-00 (now 01). My goal with this message is to spark discussion wrt this function more in depth to come to a resolution as to PCR applicability. To date, there has been discussion points on both sides of this issue. To summarize: - The LCMS MUST be referenced at call time in order to utilize the freshest mapping data. - In the event of a LCMS failure, having a cache of the mapping data could prevent call failure. Several architectural questions come to mind, a few of which are: - Is it feasible to both cache the mapping data (perform PCR) and require (a MUST) a LCMS transaction at call time? - If the UA/proxy were to cache the PCR data, would this solve requirement R5? (Minimum connectivity) - What is the most efficient entity to deploy the LCMS PCR/realtime client(s)? What is the easier to implement? Thoughts? -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 07 04:17:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENnQ3-00040T-H3; Fri, 07 Oct 2005 04:17:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENnQ2-00040E-NL for ecrit@megatron.ietf.org; Fri, 07 Oct 2005 04:17:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03419 for ; Fri, 7 Oct 2005 04:17:28 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENnZH-00023p-Eu for ecrit@ietf.org; Fri, 07 Oct 2005 04:27:04 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j978HJ96009770 for ; Fri, 7 Oct 2005 10:17:19 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j978HJpT021711 for ; Fri, 7 Oct 2005 10:17:19 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 7 Oct 2005 10:16:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Oct 2005 10:16:53 +0200 Message-ID: Thread-Topic: Internet-Drafts Submission Cutoff Dates for the 64th IETF Meeting in Vancouver, British Columbia, Canada Thread-Index: AcXK9NExqY69/5+9Q++8AIzMEjCGCQAIK14w From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 07 Oct 2005 08:16:53.0837 (UTC) FILETIME=[79D13FD0:01C5CB17] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] WG: Internet-Drafts Submission Cutoff Dates for the 64th IETF Meeting in Vancouver, British Columbia, Canada X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org please keep the submission deadlines in mind.=20 -----Urspr=FCngliche Nachricht----- Von: ietf-announce-bounces@ietf.org = [mailto:ietf-announce-bounces@ietf.org] Im Auftrag von = ietf-secretariat@ietf.org Gesendet: Freitag, 7. Oktober 2005 06:00 An: ietf-announce@ietf.org Betreff: Internet-Drafts Submission Cutoff Dates for the 64th IETF = Meeting in Vancouver, British Columbia, Canada=20 There are two (2) Internet-Draft cutoff dates for the 64th=20 IETF Meeting in Vancouver, British Columbia, Canada: October 17th: Cutoff Date for Initial (i.e., version -00)=20 Internet-Draft Submissions=20 All initial Internet-Drafts (version -00) must be submitted by Monday,=20 October 17th at 9:00 AM ET. As always, all initial submissions with a=20 filename beginning with "draft-ietf" must be approved by the=20 appropriate WG Chair before they can be processed or announced. The=20 Secretariat would appreciate receiving WG Chair approval by Monday,=20 October 10th at 9:00 AM ET. October 24th: Cutoff Date for Revised (i.e., version -01 and higher)=20 Internet-Draft Submissions=20 All revised Internet-Drafts (version -01 and higher) must be submitted=20 by Monday, October 24th at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective=20 cutoff dates will not be made available in the Internet-Drafts=20 directory or announced until on or after Monday, November 7th at 9:00=20 AM ET, when Internet-Draft posting resumes. Please do not wait until=20 the last minute to submit. Thank you for your understanding and cooperation. If you have any=20 questions or concerns, then please send a message to=20 internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 64th IETF Meeting can be found at = http://www.ietf.org/meetings/cutoff_dates_64.html. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 07 18:10:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EO0Q9-0003X7-3r; Fri, 07 Oct 2005 18:10:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EO0Q7-0003U3-P0 for ecrit@megatron.ietf.org; Fri, 07 Oct 2005 18:10:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28344 for ; Fri, 7 Oct 2005 18:10:24 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EO0ZU-000712-Fr for ecrit@ietf.org; Fri, 07 Oct 2005 18:20:09 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j97MAHSJ016779 for ; Sat, 8 Oct 2005 00:10:17 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j97MAEnJ028216 for ; Sat, 8 Oct 2005 00:10:17 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 8 Oct 2005 00:10:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sat, 8 Oct 2005 00:09:34 +0200 Message-ID: Thread-Topic: Clarifications and Current Status Thread-Index: AcXLi8zvP3rHx/qgRO6SrVEE1xEG2A== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 07 Oct 2005 22:10:11.0455 (UTC) FILETIME=[E2B850F0:01C5CB8B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] Clarifications and Current Status X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi all,=20 Based on the recent discussions on the mailing list we (the chairs) had an off-line discussions with our ADs. They expressed the desire to make progress with our chartered items before we enhance the scope of our work.=20 During the interim meeting we already discussed the need for an additional document. The recent contribution by James and Andy provides an input to the architecture discussion in addition to Henning's previous architecture document. There is no problem to have these type of discussions in the working group. Ideally, they should help us to make better progress of the requirements/threats document. However, we do not want to create an artifical dependency between such a "framework" and the requirements/threats documents. =20 The chairs are convinced that the work on the mapping protocol (as part of the requirements, the security threats and finally as a protocol solution) is certainly not a wrong approach even if we recognize that additional work needs to be started once we understand the architecture entirely. Although this is the main focus of our work the requirements and the security threats document go beyond describing purely mapping protocol specific requirements and threats (at least in some places). If the additionally described aspects are within the scope of the charter and do not prevent us from making progress then there might not be a reason to drop them from the existing documents. For the sake of making progress it might be better to postpone additional requirements and their solutions to a later stage.=20 In the last few weeks we have received a number of review comments for the requirements document. The security threats document has not seen the same number of reviews. This is somewhat unfortunate since the security aspects demand our attention. For the next IETF meeting we will see a draft update of the requirements document. Regarding the security threats document Tom might also be willing to produce a draft update if we receive review comments. Finally, the chairs hope to see draft updates of the mapping protocol proposals reflecting the feedback from the last IETF meeting and also from the mailing list discussions. Please keep the deadlines in mind.=20 Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Oct 08 12:37:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOHha-0007yd-1H; Sat, 08 Oct 2005 12:37:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOHhY-0007u9-53 for ecrit@megatron.ietf.org; Sat, 08 Oct 2005 12:37:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29670 for ; Sat, 8 Oct 2005 12:37:30 -0400 (EDT) Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOHr1-0004EA-7l for ecrit@ietf.org; Sat, 08 Oct 2005 12:47:24 -0400 Received: from zctfhxm0.corp.nortel.com (zctfhxm0.corp.nortel.com [47.164.129.155]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j98GbBT02798 for ; Sat, 8 Oct 2005 18:37:11 +0200 (MEST) Received: from zcarhxp0.corp.nortel.com ([47.129.230.91]) by zctfhxm0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 8 Oct 2005 18:37:11 +0200 Received: from [127.0.0.1] ([47.130.16.151] RDNS failed) by zcarhxp0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 8 Oct 2005 12:37:09 -0400 Message-ID: <4347F5B1.3050903@nortel.com> Date: Sat, 08 Oct 2005 12:37:05 -0400 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Oct 2005 16:37:10.0117 (UTC) FILETIME=[8753D950:01C5CC26] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Subject: [Ecrit] Comments on ecrit-requirements-00 section 7 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org 1. Introduction -------------- The first paragraph is repeated in the third, hence can be deleted. The second paragraph isn't totally accurate and not really useful, so should be deleted too. Third paragraph, first sentence: "appears" should be "appear". Fourth para should be moved down, since the final para relates to mediated resolution only. The fourth para should also be split, with the part beginning "Since servers may be used ..." going to a new para. This new para is fairly closely related to the final one. Fifth para (which moves up) should begin: "Caller-based resolution ..." since that is what it relates to. Final para, part beginning with "In addition, the caller probably does not care..." doesn't seem helpful. If it were really true, why are we taking the trouble to map to precisely the right PSAP? Delete from here to the end of the existing paragraph. I1 motivation. ------------- The motivation as stated is really an elaboration of the requirement and could be merged into that requirement. The actual motivation is probably: "Motivation: Routing to the wrong PSAP will result in delays in handling emergencies as calls are redirected, and result in inefficient use of PSAP resources at the initial point of contact." D5 motivation ------------- The existing text is not a motivation, but a statement of a solution. The motivation (if we even bother to state something so obvious) is that the faster emergency services can be invoked, the more favourable the likely outcome. I7 ------------- Is the phrase "emergency address resolution information" clear? If I understand correctly, the intent is that the entity requesting mapping should be able to determine the source of the data in the mapping database that was used to generate the returned mapping. Could someone confirm that this is the intended requirement? I assume the motivation for this requirement is to provide operational traceability in case of errors. This might be stated. Gotta go. More in another E-mail. Tom Taylor _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Oct 09 13:07:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOeeV-0000v8-RP; Sun, 09 Oct 2005 13:07:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOeeU-0000uu-64 for ecrit@megatron.ietf.org; Sun, 09 Oct 2005 13:07:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27805 for ; Sun, 9 Oct 2005 13:07:55 -0400 (EDT) Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EOeoC-0000Ys-MZ for ecrit@ietf.org; Sun, 09 Oct 2005 13:18:02 -0400 Received: (qmail invoked by alias); 09 Oct 2005 17:07:35 -0000 Received: from p54984B52.dip.t-dialin.net (EHLO [192.168.2.101]) [84.152.75.82] by mail.gmx.net (mp025) with SMTP; 09 Oct 2005 19:07:35 +0200 X-Authenticated: #29516787 Message-ID: <43494E4B.3000000@gmx.net> Date: Sun, 09 Oct 2005 19:07:23 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 1.1 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Subject: [Ecrit] ECRIT meeting slot in Vancouver X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is our meeting slot in the current plan (subject to change): MONDAY, November 7, 2005 1300-1500 Afternoon Session I APP lemonade Enhancements to Internet email to Support Diverse Service Environments WG INT ipdvb IP over Digital Video Broadcast WG INT l2vpn Layer 2 Virtual Private Networks WG OPS capwap Control and Provisioning of Wireless Access Points WG OPS v6ops IPv6 Operations WG SEC dkim Domain Keys Identified Mail BOF TSV ecrit Emergency Context Resolution with Internet Technologies WG TSV ippm IP Performance Metrics WG _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 10 23:05:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPASP-0001D1-GJ; Mon, 10 Oct 2005 23:05:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPASO-0001Cw-7L for ecrit@megatron.ietf.org; Mon, 10 Oct 2005 23:05:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10528 for ; Mon, 10 Oct 2005 23:05:33 -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.43) id 1EPAcO-0001TY-Oq for ecrit@ietf.org; Mon, 10 Oct 2005 23:15:58 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 10 Oct 2005 20:05:26 -0700 X-IronPort-AV: i="3.97,196,1125903600"; d="scan'208"; a="664890978:sNHT24385182" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9B35N4V023899; Mon, 10 Oct 2005 20:05:23 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Oct 2005 20:05:23 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.120.199]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Oct 2005 20:05:22 -0700 Message-Id: <4.3.2.7.2.20051010220429.027d2fd0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 10 Oct 2005 22:05:21 -0500 To: Hannes Tschofenig , ECRIT From: "James M. Polk" Subject: Re: [Ecrit] ECRIT meeting slot in Vancouver In-Reply-To: <43494E4B.3000000@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 11 Oct 2005 03:05:22.0542 (UTC) FILETIME=[9E96F8E0:01C5CE10] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Seems like a pretty good set of WGs to conflict with - meaning little to no overlap. At 07:07 PM 10/9/2005 +0200, Hannes Tschofenig wrote: >This is our meeting slot in the current plan >(subject to change): > >MONDAY, November 7, 2005 > >1300-1500 Afternoon Session I >APP lemonade Enhancements to Internet email to Support Diverse Service >Environments WG >INT ipdvb IP over Digital Video Broadcast WG >INT l2vpn Layer 2 Virtual Private Networks WG >OPS capwap Control and Provisioning of Wireless Access Points WG >OPS v6ops IPv6 Operations WG >SEC dkim Domain Keys Identified Mail BOF >TSV ecrit Emergency Context Resolution with Internet Technologies WG >TSV ippm IP Performance Metrics WG > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 12 19:40:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPqD6-00022A-Lz; Wed, 12 Oct 2005 19:40:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPqD4-000222-Rt for ecrit@megatron.ietf.org; Wed, 12 Oct 2005 19:40:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12234 for ; Wed, 12 Oct 2005 19:40:28 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPqNQ-0000KS-Pd for ecrit@ietf.org; Wed, 12 Oct 2005 19:51:18 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Wed, 12 Oct 2005 19:40:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] ECRIT requirements: R5 reprise Date: Wed, 12 Oct 2005 16:40:13 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657503547B1C@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] ECRIT requirements: R5 reprise Thread-Index: AcW9SoHRbTNX0xvDQ7OylzI/OUaxtgSOXfYA From: "Roger Marshall" To: "Tom-PT Taylor" , "Andrew Newton" X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org All: ECRIT Requirements, outstanding issues. Back to finishing up the easy stuff before the next draft revision. [Compare with existing R5 in http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-00.txt ] See the thread. Per the contribution below, I propose that we replace the original R5 with Ted's version of the text, since I think that the language "SHOULD allow" already protects which equates to "SHOULD NOT inhibit". Besides, I generally like stating requirements in the positive, rather than what ought not to be (where possible). A. R5(Ted's): Alternate Mapping Sources: The mapping protocol=20 SHOULD allow for alternative redundant sources of mapping information,=20 possibly of different degrees of currency. B. R5(Andy's): The mapping protocol SHOULD NOT inhibit the deployment of alternative redundant sources of mapping information, possibly of=20 different degrees of currency. Motivation: This provides the possibility of having available=20 alternative sources of mapping information when the normal source is=20 unavailable or unreachable, without specifying the means by which=20 the alternative source is created or updated. Andy, can you live with req. form A? Any others object to form A? Roger Marshall >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Tom-PT Taylor >Sent: Monday, September 19, 2005 11:46 AM >To: Andrew Newton >Cc: ecrit@ietf.org >Subject: Re: [Ecrit] ECRIT requirements: R5 reprise > >I'll buy your tweak, and I do apologize: it was Ted, not Marc. > >Andrew Newton wrote: >>=20 >> On Sep 19, 2005, at 1:52 PM, Tom-PT Taylor wrote: >>=20 >>> We had a fair-sized discussion on R5 at the beginning of=20 >July. Marc=20 >>> formulated an alternative statement that seemed to hold promise. =20 >>> Andrew ignored it and quarelled with Henning instead. I =20 >suggest we=20 >>> go with Marc's formulation with a slight tweak: >>=20 >>=20 >> I did not see Marc's message, and still do not see it in my local =20 >> copy or the IETF archives (I'm not doubting it was sent, I'm just =20 >> curious why I missed it). >>=20 >> BTW, I was not the only one with objections to R5. Ted proposed an=20 >> alternative as well. >>=20 >>> "R5: The mapping protocol should allow for alternative redundant=20 >>> sources of mapping information, possibly of different degrees of=20 >>> currency. >>> >>> "Motivation: This provides the possibility of having available=20 >>> alternative sources of mapping information when the normal=20 >source is=20 >>> unavailable or unreachable, without specifying the means by which=20 >>> the alternative source is created or updated." >>> >>> I think this proposition has concrete implications for protocol=20 >>> design, hence should be stated. >>=20 >>=20 >> Well, I like this much better than the current version. Perhaps a=20 >> slight tweak: >>=20 >> R5: The mapping protocol should not inhibit the deployment of=20 >> alternative redundant sources of mapping information, possibly of=20 >> different degrees of currency." >>=20 >> -andy >>=20 >>=20 > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 13 00:14:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPuTr-0006io-4a; Thu, 13 Oct 2005 00:14:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPuTp-0006ie-Sd for ecrit@megatron.ietf.org; Thu, 13 Oct 2005 00:14:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22046 for ; Thu, 13 Oct 2005 00:14:06 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPueG-0005xG-Fv for ecrit@ietf.org; Thu, 13 Oct 2005 00:24:57 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id for ; Thu, 13 Oct 2005 00:13:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] Editorial comments on ecrit-requirements-00 section 1, Introduction Date: Wed, 12 Oct 2005 21:13:58 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657503547C20@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Editorial comments on ecrit-requirements-00 section 1, Introduction Thread-Index: AcXMJqhHblpY8zfKSuqDOH2z7kvmnQDYBE2w From: "Roger Marshall" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org All: Baseline document is http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-00.txt See comments in-line within "[brackets]". [rsm - Reworded text as related to the upper portion of Section 1, (Introduction), changed for readability. Here's how the proposed text reads: Users of both voice-centric (telephone-like) and non voice type=20 services (e.g. text messaging for hearing disabled users,=20 (RFC 3351) have an expectation to be able to initiate a request=20 for help in case of an emergency. Unfortunately, the existing mechanisms to support emergency calls=20 that have evolved within the public=20 circuit-switched telephone network (PSTN), are not appropriate to=20 handle evolving IP-based voice, text and real-time multimedia=20 communications. This document outlines the key requirements=20 that IP-based end systems and network elements, such as SIP proxies,=20 need to satisfy in order to provide emergency call services, which at=20 a minimum, offer the same functionality as existing PSTN services, with=20 the additional overall goal of making emergency calling more robust,=20 less-costly to implement, and multimedia-capable. [rsm - Consolidated original paragraphs 1 and 2, and modified the wording in the=20 original paragraph 3.] Thanks. Roger Marshall. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 13 00:11:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPuR1-0005U4-Vo; Thu, 13 Oct 2005 00:11:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPuR0-0005Tz-MV for ecrit@megatron.ietf.org; Thu, 13 Oct 2005 00:11:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21954 for ; Thu, 13 Oct 2005 00:11:10 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPubS-0005tq-2J for ecrit@ietf.org; Thu, 13 Oct 2005 00:22:02 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Thu, 13 Oct 2005 00:10:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Comments on ecrit-requirements-00 section 7 Date: Wed, 12 Oct 2005 21:10:56 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657503547C1E@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Comments on ecrit-requirements-00 section 7 Thread-Index: AcXMJqhHblpY8zfKSuqDOH2z7kvmnQDelHKw From: "Roger Marshall" To: "Tom-PT Taylor" , X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Tom: Thanks for your comments. Please see my responses in-line within "[brackets]"). I have also included the entire intro to sect 7, as it's currently rewritten (inserted in middle), based on comments (some Tom's, some my own, and some unresolved still). Baseline document is http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-00.txt Thanks. Roger Marshall.=20 >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Tom-PT Taylor >Sent: Saturday, October 08, 2005 9:37 AM >To: ecrit@ietf.org >Subject: [Ecrit] Comments on ecrit-requirements-00 section 7 > >1. Introduction >-------------- >The first paragraph is repeated in the third, hence can be=20 >deleted. The second paragraph isn't totally accurate and not=20 >really useful, so should be deleted too. [rsm - Paragraph 1 merged into paragraph 3. Paragraph 2 has been rewritten as shown below: Given the requirement from the previous section, that of a single=20 (or small number of) emergency identifier(s) which are independent of=20 the caller's location, and since PSAPs only serve a limited geographic=20 region, and for reasons of jurisdictional and local knowledge, having the=20 call reach the appropriate PSAP based on a mapping protocol, is=20 crucial. ] > >Third paragraph, first sentence: "appears" should be "appear". [rsm - I've changed Section 7, paragraph 3 from: "There appears to be two basic architectures..."=20 to=20 "There are two basic architectures described..." ] > >Fourth para should be moved down, since the final para relates=20 >to mediated resolution only. The fourth para should also be=20 >split, with the part beginning "Since servers may be used ..."=20 >going to a new para.=20 > This new para is fairly closely related to the final one. [rsm - Split the original paragraph into two parts, moving them both down, second and third from the end, respectively.] > >Fifth para (which moves up) should begin: "Caller-based=20 >resolution ..."=20 >since that is what it relates to. [rsm - rewording of section includes this change (see at end).] > >Final para, part beginning with "In addition, the caller=20 >probably does not care..." doesn't seem helpful. If it were=20 >really true, why are we taking the trouble to map to precisely=20 >the right PSAP? Delete from here to the end of the existing paragraph. [rsm - above paragraph rewritten for clarity, see complete Section 7 intro text (proposed, below), along with some additional comments w/requests for input): Section 7 - Mapping Protocol Given the requirement from the previous section, that of a single=20 (or small number of) emergency identifier(s) which are independent of=20 the caller's location, and since PSAPs only serve a limited geographic=20 region, and for reasons of jurisdictional and local knowledge, having the=20 call reach the appropriate PSAP based on a mapping protocol, is=20 crucial. There are two basic architectures described for translating an emergency identifier into the appropriate PSAP emergency address. We refer to these as caller-based and mediated. For caller-based resolution, the caller's user agent consults a mapping=20 service to determine the appropriate PSAP based on the location provided. =20 The resolution may take place well before the actual emergency call is=20 placed, or at the time of the call. For mediated resolution, a call signaling server, such as a SIP (outbound) proxy or redirect server performs this function (a request for=20 mapping) by invoking the mapping protocol. Note that this case relies on an architecture where the call is=20 effectively routed to a copy of the database, rather than having some=20 non-SIP protocol query the database. [rsm - This phrase, "a copy of the database" is confusing... which=20 database? Also, if the database is essentially the "mapping server",=20 aren't the protocols, LUMP, DNS-SOS, IRIS all "non-SIP" protocols? =20 Not sure the average reader will know what is meant here. Comments requested.] Since servers may be used as outbound proxy servers by=20 clients that are not in the same geographic area as the proxy server, any=20 proxy server has to be able to translate any caller location to the=20 appropriate PSAP. (A traveler may, for example, accidentally or=20 intentionally configure its home proxy server as its outbound proxy=20 server, even while far away from home.) [rsm - The above paragraph seems confusing, based on the liberal use=20 of terms like "servers" and "proxy servers" as opposed to "mapping=20 servers", etc. Can this be reworded to make it clearer? Comments requested.] The problem at hand is more difficult to resolve than that for traditional=20 web or email services. In this case, the emergency caller only dialed an=20 emergency identifier, and depending on the location, any one of several=20 thousand PSAPs around the world could be appropriate PSAP. In=20 addition, there may be a finer resolution of routing (which the caller isn't=20 aware of), which results in a particular "accredited" PSAP (i.e. one run by local authorities) answering to call. (Many PSAPs are run by private=20 entities. For example, universities and corporations with large campuses=20 often have their own emergency response centers.) ] [rsm - now for Tom's comments to the requirements in section 7.] > >I1 motivation. >------------- >The motivation as stated is really an elaboration of the=20 >requirement and could be merged into that requirement. The=20 >actual motivation is probably: > >"Motivation: Routing to the wrong PSAP will result in delays=20 >in handling emergencies as calls are redirected, and result in=20 >inefficient use of PSAP resources at the initial point of contact." [rsm - done as proposed.] > >D5 motivation >------------- >The existing text is not a motivation, but a statement of a solution.=20 >The motivation (if we even bother to state something so=20 >obvious) is that the faster emergency services can be invoked,=20 >the more favourable the likely outcome. [rsm - I'm willing to have the obvious stated, though I've applied a slight twist to this supplied motivation, and have also merged the original text into the requirement. Here's the new motivation: Motivation: The more local the mapping output is, the more favourable=20 (in most cases) the likely outcome will be for the emergency caller. ] > >I7 >------------- >Is the phrase "emergency address resolution information"=20 >clear? If I understand correctly, the intent is that the=20 >entity requesting mapping should be able to determine the=20 >source of the data in the mapping database that was used to=20 >generate the returned mapping. Could someone confirm that=20 >this is the intended requirement? [rsm - Do we have an issue as to what is meant by "provided"? Is it the server of the data? or the creator of the data? Should these two suppliers=20 of data be rooted in separated requirements? Comments requested.] > >I assume the motivation for this requirement is to provide=20 >operational traceability in case of errors. This might be stated. [rsm - good idea. Done.] > >Gotta go. More in another E-mail. > >Tom Taylor > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 13 00:21:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPuaV-0008CI-EA; Thu, 13 Oct 2005 00:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPuaU-0008C8-Ih for ecrit@megatron.ietf.org; Thu, 13 Oct 2005 00:21:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22301 for ; Thu, 13 Oct 2005 00:20:58 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPukv-00065k-Rs for ecrit@ietf.org; Thu, 13 Oct 2005 00:31:50 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Thu, 13 Oct 2005 00:20:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] terminology Date: Wed, 12 Oct 2005 21:20:52 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657503547C23@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] terminology Thread-Index: AcW5be1hx/hChbJFQUiY+X+WRmrksQWPsXLQ From: "Roger Marshall" To: "Andrew Newton" , "Stastny Richard" X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Andy: I have not seen any feedback on this new proposed term. Would this IAP term (Internet Attachment Provider) be in addition to the already documented term AIP (Access Infrastructure Provider), since you mentioned layer 3, or would one term replace the other in your mind? To everyone: Is there any feedback on the choice of ASP (Application Service Provider), A(V)SP (incl. "Voice"), or simply VSP (Voice Service Provider) for inclusion into the requirements terminology section? Thanks. Roger Marshall. >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Andrew Newton >Sent: Wednesday, September 14, 2005 1:48 PM >To: Stastny Richard >Cc: ecrit@ietf.org >Subject: Re: [Ecrit] terminology > > >On Sep 14, 2005, at 4:41 PM, Stastny Richard wrote: > >> We should consider: why do we need this definitions for the=20 >> requirements? > >Perhaps we just need: > >Internet Attachment Provider - the entity that provides=20 >attachment to the Internet (layer 3) from a layer 2 network=20 >(i.e. this type of attachment is not considered of the same=20 >type as layer 3 tunneling). > >Voice Service Provider - the entity that provides Voice over=20 >IP service. > >-andy > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 13 08:18:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ22Q-0004tf-C5; Thu, 13 Oct 2005 08:18:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ22O-0004t8-GF for ecrit@megatron.ietf.org; Thu, 13 Oct 2005 08:18:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13850 for ; Thu, 13 Oct 2005 08:18:01 -0400 (EDT) Received: from dnsmx1rrc.telcordia.com ([128.96.20.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ2Cg-0001ZJ-6t for ecrit@ietf.org; Thu, 13 Oct 2005 08:28:58 -0400 Received: from rrc-its-ieg01.cc.telcordia.com (rrc-its-ieg01.cc.telcordia.com [128.96.109.78]) by dnsmx1rrc.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id j9DCHmE06057 for ; Thu, 13 Oct 2005 08:17:49 -0400 (EDT) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by rrc-its-ieg01.cc.telcordia.com (SMSSMTP 4.0.5.66) with SMTP id M2005101308174408865 for ; Thu, 13 Oct 2005 08:17:44 -0400 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 13 Oct 2005 08:17:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] ECRIT requirements: R5 reprise Date: Thu, 13 Oct 2005 08:17:45 -0400 Message-ID: Thread-Topic: [Ecrit] ECRIT requirements: R5 reprise Thread-Index: AcW9SoHRbTNX0xvDQ7OylzI/OUaxtgSOXfYAABqSI7A= From: "Abbott, Nadine B" To: X-OriginalArrivalTime: 13 Oct 2005 12:17:46.0147 (UTC) FILETIME=[1E8B3F30:01C5CFF0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: quoted-printable X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Any chance we could change this to refer to "repositories of mapping information" (or "stores" or something else equivalent) instead of "sources of mapping information"? For North America, the local/regional E9-1-1 jurisdictional authorities intend to be able to designate an authoritative "source" of the "mapping information." =20 It was my impression that this requirement was trying to get at allowing for it to be stored redundantly?=20 Nadine -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: Wednesday, October 12, 2005 7:40 PM To: Tom-PT Taylor; Andrew Newton Cc: ecrit@ietf.org Subject: RE: [Ecrit] ECRIT requirements: R5 reprise All: ECRIT Requirements, outstanding issues. Back to finishing up the easy stuff before the next draft revision. [Compare with existing R5 in http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-00.txt ] See the thread. Per the contribution below, I propose that we replace the original R5 with Ted's version of the text, since I think that the language "SHOULD allow" already protects which equates to "SHOULD NOT inhibit". Besides, I generally like stating requirements in the positive, rather than what ought not to be (where possible). A. R5(Ted's): Alternate Mapping Sources: The mapping protocol=20 SHOULD allow for alternative redundant sources of mapping information,=20 possibly of different degrees of currency. B. R5(Andy's): The mapping protocol SHOULD NOT inhibit the deployment of alternative redundant sources of mapping information, possibly of=20 different degrees of currency. Motivation: This provides the possibility of having available=20 alternative sources of mapping information when the normal source is=20 unavailable or unreachable, without specifying the means by which=20 the alternative source is created or updated. Andy, can you live with req. form A? Any others object to form A? Roger Marshall >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of Tom-PT Taylor >Sent: Monday, September 19, 2005 11:46 AM >To: Andrew Newton >Cc: ecrit@ietf.org >Subject: Re: [Ecrit] ECRIT requirements: R5 reprise > >I'll buy your tweak, and I do apologize: it was Ted, not Marc. > >Andrew Newton wrote: >>=20 >> On Sep 19, 2005, at 1:52 PM, Tom-PT Taylor wrote: >>=20 >>> We had a fair-sized discussion on R5 at the beginning of >July. Marc=20 >>> formulated an alternative statement that seemed to hold promise. >>> Andrew ignored it and quarelled with Henning instead. I =20 >suggest we >>> go with Marc's formulation with a slight tweak: >>=20 >>=20 >> I did not see Marc's message, and still do not see it in my local >> copy or the IETF archives (I'm not doubting it was sent, I'm just =20 >> curious why I missed it). >>=20 >> BTW, I was not the only one with objections to R5. Ted proposed an >> alternative as well. >>=20 >>> "R5: The mapping protocol should allow for alternative redundant >>> sources of mapping information, possibly of different degrees of=20 >>> currency. >>> >>> "Motivation: This provides the possibility of having available >>> alternative sources of mapping information when the normal=20 >source is >>> unavailable or unreachable, without specifying the means by which >>> the alternative source is created or updated." >>> >>> I think this proposition has concrete implications for protocol >>> design, hence should be stated. >>=20 >>=20 >> Well, I like this much better than the current version. Perhaps a >> slight tweak: >>=20 >> R5: The mapping protocol should not inhibit the deployment of >> alternative redundant sources of mapping information, possibly of=20 >> different degrees of currency." >>=20 >> -andy >>=20 >>=20 > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 13 10:41:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ4H1-0003Ir-CY; Thu, 13 Oct 2005 10:41:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ4Gz-0003Fp-D9 for ecrit@megatron.ietf.org; Thu, 13 Oct 2005 10:41:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21732 for ; Thu, 13 Oct 2005 10:41:29 -0400 (EDT) Received: from [199.117.205.100] (helo=ns2.sccx.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ4RT-0005dU-CJ for ecrit@ietf.org; Thu, 13 Oct 2005 10:52:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] terminology Date: Thu, 13 Oct 2005 09:41:03 -0500 Message-ID: <422D410BD61FC04185076AD99AA7207A011E7CD8@inilmx01.lgmt.trdo> Thread-Topic: [Ecrit] terminology Thread-Index: AcW5be1hx/hChbJFQUiY+X+WRmrksQWPsXLQABWspQA= From: "McCalmont, Patti" To: "Roger Marshall" , "Andrew Newton" , "Stastny Richard" X-OriginalArrivalTime: 13 Oct 2005 14:41:05.0459 (UTC) FILETIME=[24222030:01C5D004] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Seems like both ASP and VSP should both be part of the terminology. Voice can certainly be thought of as an application but I believe it makes it clearer to the reader to distinguish data only type of applications and voice. Is there really a need for Internet Attachment Provider? Won't ASP/VSP already cover this? Patti -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: Wednesday, October 12, 2005 11:21 PM To: Andrew Newton; Stastny Richard Cc: ecrit@ietf.org Subject: RE: [Ecrit] terminology Andy: I have not seen any feedback on this new proposed term. Would this IAP term (Internet Attachment Provider) be in addition to the already documented term AIP (Access Infrastructure Provider), since you mentioned layer 3, or would one term replace the other in your mind? To everyone: Is there any feedback on the choice of ASP (Application Service Provider), A(V)SP (incl. "Voice"), or simply VSP (Voice Service Provider) for inclusion into the requirements terminology section? Thanks. Roger Marshall. >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Andrew Newton >Sent: Wednesday, September 14, 2005 1:48 PM >To: Stastny Richard >Cc: ecrit@ietf.org >Subject: Re: [Ecrit] terminology > > >On Sep 14, 2005, at 4:41 PM, Stastny Richard wrote: > >> We should consider: why do we need this definitions for the=20 >> requirements? > >Perhaps we just need: > >Internet Attachment Provider - the entity that provides=20 >attachment to the Internet (layer 3) from a layer 2 network=20 >(i.e. this type of attachment is not considered of the same=20 >type as layer 3 tunneling). > >Voice Service Provider - the entity that provides Voice over=20 >IP service. > >-andy > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 13 12:56:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ6NC-0000ig-BW; Thu, 13 Oct 2005 12:56:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ6N7-0000iR-92 for ecrit@megatron.ietf.org; Thu, 13 Oct 2005 12:56:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28533 for ; Thu, 13 Oct 2005 12:55:56 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ6XV-0000jY-4T for ecrit@ietf.org; Thu, 13 Oct 2005 13:06:46 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Thu, 13 Oct 2005 12:55:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] terminology Date: Thu, 13 Oct 2005 09:55:32 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657503547E9F@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] terminology Thread-Index: AcW5be1hx/hChbJFQUiY+X+WRmrksQWPsXLQABWspQAAA5FHQA== From: "Roger Marshall" To: "McCalmont, Patti" , "Andrew Newton" , "Stastny Richard" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Patti: I agree this is problematic, and so I propose to clarify the A(V)SP dilemna, and supply both definitions within the requirements terminology section, something like what follows: Application Service Provider (ASP): The organization or entity that=20 provides application-layer services, which may include voice (see term=20 Voice Service Provider). This entity can be a private individual, an=20 enterprise, a government, or a service provider. An ASP is defined as=20 something more general than a Voice Service Provider, since emergency=20 calls are sometimes likely to use other media, including text and video. Note: For a particular user, the ASP may or may not be the same=20 organization as the AIP and/or ISP. Voice Service Provider (VSP): A specific type of Application Service=20 Provider which provides voice related services based on IP, such as call routing, a SIP URI, or PSTN termination. I think this helps, since both ASP and VSP are currently used separately within the draft. =20 Any objections? Thanks. Roger Marshall. >-----Original Message----- >From: McCalmont, Patti [mailto:Patti.McCalmont@intrado.com]=20 >Sent: Thursday, October 13, 2005 7:41 AM >To: Roger Marshall; Andrew Newton; Stastny Richard >Cc: ecrit@ietf.org >Subject: RE: [Ecrit] terminology > >Seems like both ASP and VSP should both be part of the terminology. >Voice can certainly be thought of as an application but I=20 >believe it makes it clearer to the reader to distinguish data=20 >only type of applications and voice. Is there really a need=20 >for Internet Attachment Provider? Won't ASP/VSP already cover this? > >Patti > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Roger Marshall >Sent: Wednesday, October 12, 2005 11:21 PM >To: Andrew Newton; Stastny Richard >Cc: ecrit@ietf.org >Subject: RE: [Ecrit] terminology > >Andy: >I have not seen any feedback on this new proposed term. Would=20 >this IAP term (Internet Attachment Provider) be in addition to=20 >the already documented term AIP (Access Infrastructure=20 >Provider), since you mentioned layer 3, or would one term=20 >replace the other in your mind? > >To everyone: >Is there any feedback on the choice of ASP (Application=20 >Service Provider), A(V)SP (incl. "Voice"), or simply VSP (Voice Service >Provider) for inclusion into the requirements terminology section? > >Thanks. > >Roger Marshall. > > > >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf=20 >>Of Andrew Newton >>Sent: Wednesday, September 14, 2005 1:48 PM >>To: Stastny Richard >>Cc: ecrit@ietf.org >>Subject: Re: [Ecrit] terminology >> >> >>On Sep 14, 2005, at 4:41 PM, Stastny Richard wrote: >> >>> We should consider: why do we need this definitions for the=20 >>> requirements? >> >>Perhaps we just need: >> >>Internet Attachment Provider - the entity that provides attachment to=20 >>the Internet (layer 3) from a layer 2 network (i.e. this type of=20 >>attachment is not considered of the same type as layer 3 tunneling). >> >>Voice Service Provider - the entity that provides Voice over IP=20 >>service. >> >>-andy >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit >> > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 13 13:04:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ6V8-0003Qv-DM; Thu, 13 Oct 2005 13:04:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ6V2-0003QX-Nv for ecrit@megatron.ietf.org; Thu, 13 Oct 2005 13:04:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29012 for ; Thu, 13 Oct 2005 13:04:08 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ6fZ-0000zQ-Uu for ecrit@ietf.org; Thu, 13 Oct 2005 13:15:07 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Thu, 13 Oct 2005 13:04:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] ECRIT requirements: R5 reprise Date: Thu, 13 Oct 2005 10:04:01 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657503547EC9@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] ECRIT requirements: R5 reprise Thread-Index: AcW9SoHRbTNX0xvDQ7OylzI/OUaxtgSOXfYAABqSI7AACjCfgA== From: "Roger Marshall" To: "Abbott, Nadine B" , X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Nadine: Are you trying to distinguish between the use of the term "sources of mapping info" as relating to the data itself as opposed to which entity supplies that data (e.g. machines vs. people)? Would it be clearer if reworded as follows?: R5: Alternate Mapping: The mapping protocol SHOULD allow for=20 alternative redundant sources of mapping services, possibly=20 containing mapping information of different degrees of=20 currency. Comments requested. Roger Marshall. >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Abbott, Nadine B >Sent: Thursday, October 13, 2005 5:18 AM >To: ecrit@ietf.org >Subject: RE: [Ecrit] ECRIT requirements: R5 reprise > >Any chance we could change this to refer to "repositories of=20 >mapping information" (or "stores" or something else=20 >equivalent) instead of "sources of mapping information"? >For North America, the local/regional E9-1-1 jurisdictional=20 >authorities intend to be able to designate an authoritative=20 >"source" of the "mapping information." =20 >It was my impression that this requirement was trying to get=20 >at allowing for it to be stored redundantly?=20 > >Nadine > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Roger Marshall >Sent: Wednesday, October 12, 2005 7:40 PM >To: Tom-PT Taylor; Andrew Newton >Cc: ecrit@ietf.org >Subject: RE: [Ecrit] ECRIT requirements: R5 reprise > > >All: >ECRIT Requirements, outstanding issues. Back to finishing up=20 >the easy stuff before the next draft revision. > >[Compare with existing R5 in >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requiremen >ts-00.txt >] > >See the thread. Per the contribution below, I propose that we=20 >replace the original R5 with Ted's version of the text, since=20 >I think that the language "SHOULD allow" already protects=20 >which equates to "SHOULD NOT inhibit". Besides, I generally=20 >like stating requirements in the positive, rather than what=20 >ought not to be (where possible). > >A. R5(Ted's): Alternate Mapping Sources: The mapping protocol=20 >SHOULD allow for alternative redundant sources of mapping=20 >information, possibly of different degrees of currency. > >B. R5(Andy's): The mapping protocol SHOULD NOT inhibit the=20 >deployment of > >alternative redundant sources of mapping information, possibly=20 >of different degrees of currency. > >Motivation: This provides the possibility of having available=20 >alternative sources of mapping information when the normal=20 >source is unavailable or unreachable, without specifying the=20 >means by which the alternative source is created or updated. > >Andy, can you live with req. form A? Any others object to form A? > >Roger Marshall > >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf=20 >>Of Tom-PT Taylor >>Sent: Monday, September 19, 2005 11:46 AM >>To: Andrew Newton >>Cc: ecrit@ietf.org >>Subject: Re: [Ecrit] ECRIT requirements: R5 reprise >> >>I'll buy your tweak, and I do apologize: it was Ted, not Marc. >> >>Andrew Newton wrote: >>>=20 >>> On Sep 19, 2005, at 1:52 PM, Tom-PT Taylor wrote: >>>=20 >>>> We had a fair-sized discussion on R5 at the beginning of >>July. Marc=20 >>>> formulated an alternative statement that seemed to hold promise. >>>> Andrew ignored it and quarelled with Henning instead. I >>suggest we >>>> go with Marc's formulation with a slight tweak: >>>=20 >>>=20 >>> I did not see Marc's message, and still do not see it in my local=20 >>> copy or the IETF archives (I'm not doubting it was sent, I'm just=20 >>> curious why I missed it). >>>=20 >>> BTW, I was not the only one with objections to R5. Ted proposed an=20 >>> alternative as well. >>>=20 >>>> "R5: The mapping protocol should allow for alternative redundant=20 >>>> sources of mapping information, possibly of different degrees of=20 >>>> currency. >>>> >>>> "Motivation: This provides the possibility of having available=20 >>>> alternative sources of mapping information when the normal >>source is >>>> unavailable or unreachable, without specifying the means by which=20 >>>> the alternative source is created or updated." >>>> >>>> I think this proposition has concrete implications for protocol=20 >>>> design, hence should be stated. >>>=20 >>>=20 >>> Well, I like this much better than the current version. Perhaps a=20 >>> slight tweak: >>>=20 >>> R5: The mapping protocol should not inhibit the deployment of=20 >>> alternative redundant sources of mapping information, possibly of=20 >>> different degrees of currency." >>>=20 >>> -andy >>>=20 >>>=20 >> >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit >> > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 13 13:09:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ6Zz-0005po-Ry; Thu, 13 Oct 2005 13:09:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ6Zv-0005oV-65 for ecrit@megatron.ietf.org; Thu, 13 Oct 2005 13:09:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29255 for ; Thu, 13 Oct 2005 13:09:10 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ6kS-00017Z-7w for ecrit@ietf.org; Thu, 13 Oct 2005 13:20:09 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 13 Oct 2005 10:09:04 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,211,1125903600"; d="scan'208"; a="13112890:sNHT24818792" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9DH8o29001757; Thu, 13 Oct 2005 13:08:56 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Oct 2005 13:08:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] ECRIT requirements: R5 reprise Date: Thu, 13 Oct 2005 13:08:51 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3A8C81A@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] ECRIT requirements: R5 reprise Thread-Index: AcW9SoHRbTNX0xvDQ7OylzI/OUaxtgSOXfYAABqSI7AACjCfgAAAZtPQ From: "Michael Hammer \(mhammer\)" To: "Roger Marshall" , "Abbott, Nadine B" , X-OriginalArrivalTime: 13 Oct 2005 17:08:52.0912 (UTC) FILETIME=[C98C1300:01C5D018] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I thought the issue was that "source" implies it is authoritative, i.e. the master source. Perhaps providers of mapping services would avoid the question of being authoritative. Mike =20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Roger Marshall > Sent: Thursday, October 13, 2005 1:04 PM > To: Abbott, Nadine B; ecrit@ietf.org > Subject: RE: [Ecrit] ECRIT requirements: R5 reprise >=20 > Nadine: > Are you trying to distinguish between the use of the term=20 > "sources of mapping info" as relating to the data itself as=20 > opposed to which entity supplies that data (e.g. machines vs. people)? >=20 > Would it be clearer if reworded as follows?: >=20 > R5: Alternate Mapping: The mapping protocol SHOULD allow for=20 > alternative redundant sources of mapping services, possibly=20 > containing mapping information of different degrees of currency. >=20 > Comments requested. >=20 > Roger Marshall. >=20 > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf=20 > >Of Abbott, Nadine B > >Sent: Thursday, October 13, 2005 5:18 AM > >To: ecrit@ietf.org > >Subject: RE: [Ecrit] ECRIT requirements: R5 reprise > > > >Any chance we could change this to refer to "repositories of mapping=20 > >information" (or "stores" or something else > >equivalent) instead of "sources of mapping information"? > >For North America, the local/regional E9-1-1 jurisdictional=20 > authorities=20 > >intend to be able to designate an authoritative "source" of the=20 > >"mapping information." > >It was my impression that this requirement was trying to get at=20 > >allowing for it to be stored redundantly? > > > >Nadine > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf=20 > >Of Roger Marshall > >Sent: Wednesday, October 12, 2005 7:40 PM > >To: Tom-PT Taylor; Andrew Newton > >Cc: ecrit@ietf.org > >Subject: RE: [Ecrit] ECRIT requirements: R5 reprise > > > > > >All: > >ECRIT Requirements, outstanding issues. Back to finishing up=20 > the easy=20 > >stuff before the next draft revision. > > > >[Compare with existing R5 in > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requiremen > >ts-00.txt > >] > > > >See the thread. Per the contribution below, I propose that=20 > we replace=20 > >the original R5 with Ted's version of the text, since I=20 > think that the=20 > >language "SHOULD allow" already protects which equates to=20 > "SHOULD NOT=20 > >inhibit". Besides, I generally like stating requirements in the=20 > >positive, rather than what ought not to be (where possible). > > > >A. R5(Ted's): Alternate Mapping Sources: The mapping protocol SHOULD=20 > >allow for alternative redundant sources of mapping information,=20 > >possibly of different degrees of currency. > > > >B. R5(Andy's): The mapping protocol SHOULD NOT inhibit the=20 > deployment=20 > >of > > > >alternative redundant sources of mapping information, possibly of=20 > >different degrees of currency. > > > >Motivation: This provides the possibility of having available=20 > >alternative sources of mapping information when the normal=20 > source is=20 > >unavailable or unreachable, without specifying the means by =20 > which the=20 > >alternative source is created or updated. > > > >Andy, can you live with req. form A? Any others object to form A? > > > >Roger Marshall > > > >>-----Original Message----- > >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf > >>Of Tom-PT Taylor > >>Sent: Monday, September 19, 2005 11:46 AM > >>To: Andrew Newton > >>Cc: ecrit@ietf.org > >>Subject: Re: [Ecrit] ECRIT requirements: R5 reprise > >> > >>I'll buy your tweak, and I do apologize: it was Ted, not Marc. > >> > >>Andrew Newton wrote: > >>>=20 > >>> On Sep 19, 2005, at 1:52 PM, Tom-PT Taylor wrote: > >>>=20 > >>>> We had a fair-sized discussion on R5 at the beginning of > >>July. Marc=20 > >>>> formulated an alternative statement that seemed to hold promise. > >>>> Andrew ignored it and quarelled with Henning instead. I > >>suggest we > >>>> go with Marc's formulation with a slight tweak: > >>>=20 > >>>=20 > >>> I did not see Marc's message, and still do not see it in my local=20 > >>> copy or the IETF archives (I'm not doubting it was sent, I'm just=20 > >>> curious why I missed it). > >>>=20 > >>> BTW, I was not the only one with objections to R5. Ted=20 > proposed an=20 > >>> alternative as well. > >>>=20 > >>>> "R5: The mapping protocol should allow for alternative redundant=20 > >>>> sources of mapping information, possibly of different degrees of=20 > >>>> currency. > >>>> > >>>> "Motivation: This provides the possibility of having available=20 > >>>> alternative sources of mapping information when the normal > >>source is > >>>> unavailable or unreachable, without specifying the means=20 > by which=20 > >>>> the alternative source is created or updated." > >>>> > >>>> I think this proposition has concrete implications for protocol=20 > >>>> design, hence should be stated. > >>>=20 > >>>=20 > >>> Well, I like this much better than the current version. =20 > Perhaps a=20 > >>> slight tweak: > >>>=20 > >>> R5: The mapping protocol should not inhibit the deployment of=20 > >>> alternative redundant sources of mapping information, possibly of=20 > >>> different degrees of currency." > >>>=20 > >>> -andy > >>>=20 > >>>=20 > >> > >> > >>_______________________________________________ > >>Ecrit mailing list > >>Ecrit@ietf.org > >>https://www1.ietf.org/mailman/listinfo/ecrit > >> > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www1.ietf.org/mailman/listinfo/ecrit > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www1.ietf.org/mailman/listinfo/ecrit > > >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 13 15:26:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ8iu-0004IH-Tr; Thu, 13 Oct 2005 15:26:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ8it-0004I9-On for ecrit@megatron.ietf.org; Thu, 13 Oct 2005 15:26:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06623 for ; Thu, 13 Oct 2005 15:26:34 -0400 (EDT) Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ8tS-0004jT-I5 for ecrit@ietf.org; Thu, 13 Oct 2005 15:37:35 -0400 Received: from [10.0.1.104] ([::ffff:64.83.8.179]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Thu, 13 Oct 2005 15:26:21 -0400 id 01588023.434EB4DD.00007A65 In-Reply-To: <8C837214C95C864C9F34F3635C2A657503547C23@SEA-EXCHVS-2.telecomsys.com> References: <8C837214C95C864C9F34F3635C2A657503547C23@SEA-EXCHVS-2.telecomsys.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] terminology Date: Thu, 13 Oct 2005 15:26:18 -0400 To: Roger Marshall , Patti McCalmont X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Oct 13, 2005, at 12:20 AM, Roger Marshall wrote: > Andy: > I have not seen any feedback on this new proposed term. Would this > IAP > term (Internet Attachment Provider) be in addition to the already > documented term AIP (Access Infrastructure Provider), since you > mentioned layer 3, or would one term replace the other in your mind? I was thinking it IAP should replace AIP. On Oct 13, 2005, at 10:41 AM, McCalmont, Patti wrote: > Seems like both ASP and VSP should both be part of the terminology. > Voice can certainly be thought of as an application but I believe it > makes it clearer to the reader to distinguish data only type of > applications and voice. Is there really a need for Internet Attachment > Provider? Won't ASP/VSP already cover this? The entity that may provide you with an IP address can be different than the entity that provides you voice service. So, no. Also, I see no need for defining ASP. We are talking about voice services here, are we not? Do we also feel the need to define Web Hosting Service Provider or Email Service Provider? Those types of entities do exist, but they aren't relevant to our problems space. The purpose of having these definitions is so that we can all refer to the same concept precisely and so anybody reading the document later on can understand what we are talking about. There is no need to define ASP if we do not intend to use it. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 13 15:27:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ8jr-0004Oz-Tj; Thu, 13 Oct 2005 15:27:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ8jr-0004Os-1D for ecrit@megatron.ietf.org; Thu, 13 Oct 2005 15:27:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06700 for ; Thu, 13 Oct 2005 15:27:33 -0400 (EDT) Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ8uP-0004jT-M0 for ecrit@ietf.org; Thu, 13 Oct 2005 15:38:34 -0400 Received: from [10.0.1.104] ([::ffff:64.83.8.179]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Thu, 13 Oct 2005 15:27:36 -0400 id 01588023.434EB528.00007A9C In-Reply-To: <8C837214C95C864C9F34F3635C2A657503547B1C@SEA-EXCHVS-2.telecomsys.com> References: <8C837214C95C864C9F34F3635C2A657503547B1C@SEA-EXCHVS-2.telecomsys.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <10B77B78-20B5-4DF5-8978-E18F0B32C155@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] ECRIT requirements: R5 reprise Date: Thu, 13 Oct 2005 15:27:34 -0400 To: Roger Marshall X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Oct 12, 2005, at 7:40 PM, Roger Marshall wrote: > Andy, can you live with req. form A? Yes. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 13 16:01:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ9H5-0005mi-QR; Thu, 13 Oct 2005 16:01:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ9H3-0005mA-GA for ecrit@megatron.ietf.org; Thu, 13 Oct 2005 16:01:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09880 for ; Thu, 13 Oct 2005 16:01:54 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ9RZ-0006JV-E0 for ecrit@ietf.org; Thu, 13 Oct 2005 16:12:53 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Thu, 13 Oct 2005 16:01:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] terminology Date: Thu, 13 Oct 2005 13:01:35 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65750354812F@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] terminology Thread-Index: AcXQLAGmNM+7aNyDQa+iLq1Cpw4wdwAA7iew From: "Roger Marshall" To: "Andrew Newton" , "Patti McCalmont" X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Andy: See comments in-line. >-----Original Message----- >From: Andrew Newton [mailto:andy@hxr.us]=20 >Sent: Thursday, October 13, 2005 12:26 PM >To: Roger Marshall; Patti McCalmont >Cc: ECRIT >Subject: Re: [Ecrit] terminology > > >On Oct 13, 2005, at 12:20 AM, Roger Marshall wrote: > >> Andy: >> I have not seen any feedback on this new proposed term. Would this=20 >> IAP term (Internet Attachment Provider) be in addition to=20 >the already=20 >> documented term AIP (Access Infrastructure Provider), since you=20 >> mentioned layer 3, or would one term replace the other in your mind? > >I was thinking it IAP should replace AIP. Agreed. IAP has now replaced AIP. > > >On Oct 13, 2005, at 10:41 AM, McCalmont, Patti wrote: >> Seems like both ASP and VSP should both be part of the terminology. >> Voice can certainly be thought of as an application but I believe it=20 >> makes it clearer to the reader to distinguish data only type of=20 >> applications and voice. Is there really a need for Internet=20 >Attachment=20 >> Provider? Won't ASP/VSP already cover this? > >The entity that may provide you with an IP address can be=20 >different than the entity that provides you voice service. So, no. > >Also, I see no need for defining ASP. We are talking about=20 >voice services here, are we not? Do we also feel the need to=20 >define Web Hosting Service Provider or Email Service Provider?=20 > Those types of =20 >entities do exist, but they aren't relevant to our problems space. =20 >The purpose of having these definitions is so that we can all=20 >refer to the same concept precisely and so anybody reading the=20 >document later on can understand what we are talking about. =20 >There is no need to define ASP if we do not intend to use it. The problem is that we have already had a definition of ASP, though it was more specifically, A(V)SP, which is even more awkward and confusing. In addition, we have stated within the Introduction (and elsewhere) that multimedia (e.g. text msgs., video), must be supportable, not only voice. While you're mostly right about the problem space dealing with voice, its not 100%, but rather more like a 95%/5% split for voice/other-media-modes, respectively. I think its reasonable to leave ASP in there, and also include the term VSP (a subset provider) specifically as it applies to voice related services. Roger. > >-andy > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 13 16:22:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ9bC-0002Nx-1v; Thu, 13 Oct 2005 16:22:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ9b9-0002Ns-Vh for ecrit@megatron.ietf.org; Thu, 13 Oct 2005 16:22:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15185 for ; Thu, 13 Oct 2005 16:22:40 -0400 (EDT) Received: from [199.117.205.100] (helo=ns2.sccx.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ9lj-0008MS-Ln for ecrit@ietf.org; Thu, 13 Oct 2005 16:33:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] terminology Date: Thu, 13 Oct 2005 15:22:21 -0500 Message-ID: <422D410BD61FC04185076AD99AA7207A011E7D9F@inilmx01.lgmt.trdo> Thread-Topic: [Ecrit] terminology Thread-Index: AcW5be1hx/hChbJFQUiY+X+WRmrksQWPsXLQABWspQAAA5FHQAAIgW/w From: "McCalmont, Patti" To: "Roger Marshall" , "Andrew Newton" , "Stastny Richard" X-OriginalArrivalTime: 13 Oct 2005 20:22:23.0634 (UTC) FILETIME=[D213A720:01C5D033] X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This looks good. Patti -----Original Message----- From: Roger Marshall [mailto:RMarshall@telecomsys.com]=20 Sent: Thursday, October 13, 2005 11:56 AM To: McCalmont, Patti; Andrew Newton; Stastny Richard Cc: ecrit@ietf.org Subject: RE: [Ecrit] terminology Patti: I agree this is problematic, and so I propose to clarify the A(V)SP dilemna, and supply both definitions within the requirements terminology section, something like what follows: Application Service Provider (ASP): The organization or entity that=20 provides application-layer services, which may include voice (see term=20 Voice Service Provider). This entity can be a private individual, an=20 enterprise, a government, or a service provider. An ASP is defined as=20 something more general than a Voice Service Provider, since emergency=20 calls are sometimes likely to use other media, including text and video. Note: For a particular user, the ASP may or may not be the same=20 organization as the AIP and/or ISP. Voice Service Provider (VSP): A specific type of Application Service=20 Provider which provides voice related services based on IP, such as call routing, a SIP URI, or PSTN termination. I think this helps, since both ASP and VSP are currently used separately within the draft. =20 Any objections? Thanks. Roger Marshall. >-----Original Message----- >From: McCalmont, Patti [mailto:Patti.McCalmont@intrado.com]=20 >Sent: Thursday, October 13, 2005 7:41 AM >To: Roger Marshall; Andrew Newton; Stastny Richard >Cc: ecrit@ietf.org >Subject: RE: [Ecrit] terminology > >Seems like both ASP and VSP should both be part of the terminology. >Voice can certainly be thought of as an application but I=20 >believe it makes it clearer to the reader to distinguish data=20 >only type of applications and voice. Is there really a need=20 >for Internet Attachment Provider? Won't ASP/VSP already cover this? > >Patti > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Roger Marshall >Sent: Wednesday, October 12, 2005 11:21 PM >To: Andrew Newton; Stastny Richard >Cc: ecrit@ietf.org >Subject: RE: [Ecrit] terminology > >Andy: >I have not seen any feedback on this new proposed term. Would=20 >this IAP term (Internet Attachment Provider) be in addition to=20 >the already documented term AIP (Access Infrastructure=20 >Provider), since you mentioned layer 3, or would one term=20 >replace the other in your mind? > >To everyone: >Is there any feedback on the choice of ASP (Application=20 >Service Provider), A(V)SP (incl. "Voice"), or simply VSP (Voice Service >Provider) for inclusion into the requirements terminology section? > >Thanks. > >Roger Marshall. > > > >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf=20 >>Of Andrew Newton >>Sent: Wednesday, September 14, 2005 1:48 PM >>To: Stastny Richard >>Cc: ecrit@ietf.org >>Subject: Re: [Ecrit] terminology >> >> >>On Sep 14, 2005, at 4:41 PM, Stastny Richard wrote: >> >>> We should consider: why do we need this definitions for the=20 >>> requirements? >> >>Perhaps we just need: >> >>Internet Attachment Provider - the entity that provides attachment to=20 >>the Internet (layer 3) from a layer 2 network (i.e. this type of=20 >>attachment is not considered of the same type as layer 3 tunneling). >> >>Voice Service Provider - the entity that provides Voice over IP=20 >>service. >> >>-andy >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit >> > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 13 17:17:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQARh-00034Y-GI; Thu, 13 Oct 2005 17: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 1EQARf-000347-Gj for ecrit@megatron.ietf.org; Thu, 13 Oct 2005 17:17:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18313 for ; Thu, 13 Oct 2005 17:16:54 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQAcE-0001SG-0m for ecrit@ietf.org; Thu, 13 Oct 2005 17:27:55 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Thu, 13 Oct 2005 17:16:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Comment on ecrit-requirements-00 item L10 Date: Thu, 13 Oct 2005 14:16:45 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657503548282@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Comment on ecrit-requirements-00 item L10 Thread-Index: AcXE1slmQT60S4eLSoyIE9dOMV/0hgARHu7AAAoKoKACvdADcA== From: "Roger Marshall" To: "Thomson, Martin" X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: quoted-printable Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Martin: I think your point is valid. I take this as the mapping server. I've also changed the requirement to reflect this. New proposed text for L10: Reference Datum: The mapping server MUST understand WGS-84=20 coordinate reference system and may understand other reference=20 systems. Thanks. Roger Marshall >-----Original Message----- >From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]=20 >Sent: Thursday, September 29, 2005 3:19 PM >To: Roger Marshall >Cc: ECRIT >Subject: RE: [Ecrit] Comment on ecrit-requirements-00 item L10 > >You need to identify what you mean by "The server", the=20 >context doesn't make that clear. Are we talking about an LCMS=20 >server? If so, use "LCMS servers MUST...". > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Roger Marshall >Sent: Friday, 30 September 2005 3:35 AM >To: Clive D.W. Feather; Tim Dunn >Cc: ECRIT >Subject: RE: [Ecrit] Comment on ecrit-requirements-00 item L10 > >Clive: > >With the idea of keeping the requirements more general (not=20 >saying your system can't impose more detailed requirements on=20 >top), I believe that the following single requirement proposed=20 >by Henning is sufficient: > >L10. Reference Datum: "The server MUST understand WGS-84=20 >coordinate reference system and MAY understand other reference=20 >systems." > >Roger Marshall > > >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf=20 >>Of Clive D.W. Feather >>Sent: Thursday, September 29, 2005 2:17 AM >>To: Tim Dunn >>Cc: 'ECRIT' >>Subject: Re: [Ecrit] Comment on ecrit-requirements-00 item L10 >> >>Tim Dunn said: >>> How about an alternate presentation of the requirement,=20 >specifically: >>[...] >> >>Having read the discussion over the last couple of days, what I think=20 >>is needed is: >> >>A: There MUST be a way in the protocol for the caller's equipment to >> negotiate a choice of coordinate system with the PSAP. >>Aa: Calling equipment MUST be able to convert its location to any of=20 >>the >> coordinate systems it offers in the negotiation. >>Ab: PSAP equipment MUST be able to convert the received location from=20 >>any >> of the coordinate systems it offers in the negotiation to that >> required internally. >>B: Both calling equipment and PSAP MUST offer WGS-84 as part of the >> negotiation (even if not the first choice). [This could be=20 >>implemented >> either by requiring it to be on any lists, or by making it the=20 >>fallback >> if negotiation fails.] >> >>Then, if the negotiation is the common one of "offer an ordered list,=20 >>use the first one on both side's lists": >> >> UK CPE offers: OSGB, WGS-84 >> other CPE offers: XXX, YYY, WGS-84 >> UK PSAP accepts: OSGB, WGS-84 >> other PSAP accepts: ZZZ, WGS-84 >> >>(where XXX, YYY, ZZZ are other systems) and all works. >> >>--=20 >>Clive D.W. Feather | Work: | Tel: +44=20 >>20 8495 6138 >>Internet Expert | Home: | Fax: +44=20 >>870 051 9937 >>Demon Internet | WWW: http://www.davros.org | Mobile: +44=20 >>7973 377646 >>Thus plc | | >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit >> > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > >--------------------------------------------------------------- >--------------------------------- >This message is for the designated recipient only and may=20 >contain privileged, proprietary, or otherwise private information. =20 >If you have received it in error, please notify the sender=20 >immediately and delete the original. Any unauthorized use of=20 >this email is prohibited. >--------------------------------------------------------------- >--------------------------------- >[mf2] > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 13 18:00:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQB7n-0007yD-Dz; Thu, 13 Oct 2005 18:00:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQB7m-0007vi-9c for ecrit@megatron.ietf.org; Thu, 13 Oct 2005 18:00:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20439 for ; Thu, 13 Oct 2005 18:00:26 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQBIN-0002Xc-0M for ecrit@ietf.org; Thu, 13 Oct 2005 18:11:27 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Thu, 13 Oct 2005 18:00:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] ECRIT requirements: R5 reprise Date: Thu, 13 Oct 2005 15:00:18 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657503548353@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] ECRIT requirements: R5 reprise Thread-Index: AcW9SoHRbTNX0xvDQ7OylzI/OUaxtgSOXfYAABqSI7AACjCfgAAAZtPQAAlOhfA= From: "Roger Marshall" To: "Michael Hammer \(mhammer\)" , "Abbott, Nadine B" , X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Michael: This makes me question how a master source (which itself implies a sole entity) could be required to be redundant, with variant levels of currency. I take the term source as "copies" of data used for mapping. Roger. >-----Original Message----- >From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 >Sent: Thursday, October 13, 2005 10:09 AM >To: Roger Marshall; Abbott, Nadine B; ecrit@ietf.org >Subject: RE: [Ecrit] ECRIT requirements: R5 reprise > >I thought the issue was that "source" implies it is authoritative, i.e. >the master source. > >Perhaps providers of mapping services would avoid the question=20 >of being authoritative. > >Mike >=20 > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf=20 >> Of Roger Marshall >> Sent: Thursday, October 13, 2005 1:04 PM >> To: Abbott, Nadine B; ecrit@ietf.org >> Subject: RE: [Ecrit] ECRIT requirements: R5 reprise >>=20 >> Nadine: >> Are you trying to distinguish between the use of the term=20 >"sources of=20 >> mapping info" as relating to the data itself as opposed to which=20 >> entity supplies that data (e.g. machines vs. people)? >>=20 >> Would it be clearer if reworded as follows?: >>=20 >> R5: Alternate Mapping: The mapping protocol SHOULD allow for=20 >> alternative redundant sources of mapping services, possibly=20 >containing=20 >> mapping information of different degrees of currency. >>=20 >> Comments requested. >>=20 >> Roger Marshall. >>=20 >> >-----Original Message----- >> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> On Behalf >> >Of Abbott, Nadine B >> >Sent: Thursday, October 13, 2005 5:18 AM >> >To: ecrit@ietf.org >> >Subject: RE: [Ecrit] ECRIT requirements: R5 reprise >> > >> >Any chance we could change this to refer to "repositories=20 >of mapping=20 >> >information" (or "stores" or something else >> >equivalent) instead of "sources of mapping information"? >> >For North America, the local/regional E9-1-1 jurisdictional >> authorities >> >intend to be able to designate an authoritative "source" of the=20 >> >"mapping information." >> >It was my impression that this requirement was trying to get at=20 >> >allowing for it to be stored redundantly? >> > >> >Nadine >> > >> >-----Original Message----- >> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> On Behalf >> >Of Roger Marshall >> >Sent: Wednesday, October 12, 2005 7:40 PM >> >To: Tom-PT Taylor; Andrew Newton >> >Cc: ecrit@ietf.org >> >Subject: RE: [Ecrit] ECRIT requirements: R5 reprise >> > >> > >> >All: >> >ECRIT Requirements, outstanding issues. Back to finishing up >> the easy >> >stuff before the next draft revision. >> > >> >[Compare with existing R5 in >> >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requiremen >> >ts-00.txt >> >] >> > >> >See the thread. Per the contribution below, I propose that >> we replace >> >the original R5 with Ted's version of the text, since I >> think that the >> >language "SHOULD allow" already protects which equates to >> "SHOULD NOT >> >inhibit". Besides, I generally like stating requirements in the=20 >> >positive, rather than what ought not to be (where possible). >> > >> >A. R5(Ted's): Alternate Mapping Sources: The mapping=20 >protocol SHOULD=20 >> >allow for alternative redundant sources of mapping information,=20 >> >possibly of different degrees of currency. >> > >> >B. R5(Andy's): The mapping protocol SHOULD NOT inhibit the >> deployment >> >of >> > >> >alternative redundant sources of mapping information, possibly of=20 >> >different degrees of currency. >> > >> >Motivation: This provides the possibility of having available=20 >> >alternative sources of mapping information when the normal >> source is >> >unavailable or unreachable, without specifying the means by >> which the >> >alternative source is created or updated. >> > >> >Andy, can you live with req. form A? Any others object to form A? >> > >> >Roger Marshall >> > >> >>-----Original Message----- >> >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> >On Behalf >> >>Of Tom-PT Taylor >> >>Sent: Monday, September 19, 2005 11:46 AM >> >>To: Andrew Newton >> >>Cc: ecrit@ietf.org >> >>Subject: Re: [Ecrit] ECRIT requirements: R5 reprise >> >> >> >>I'll buy your tweak, and I do apologize: it was Ted, not Marc. >> >> >> >>Andrew Newton wrote: >> >>>=20 >> >>> On Sep 19, 2005, at 1:52 PM, Tom-PT Taylor wrote: >> >>>=20 >> >>>> We had a fair-sized discussion on R5 at the beginning of >> >>July. Marc=20 >> >>>> formulated an alternative statement that seemed to hold=20 > promise. >> >>>> Andrew ignored it and quarelled with Henning instead. I >> >>suggest we >> >>>> go with Marc's formulation with a slight tweak: >> >>>=20 >> >>>=20 >> >>> I did not see Marc's message, and still do not see it in=20 >my local=20 >> >>> copy or the IETF archives (I'm not doubting it was sent,=20 >I'm just=20 >> >>> curious why I missed it). >> >>>=20 >> >>> BTW, I was not the only one with objections to R5. Ted >> proposed an >> >>> alternative as well. >> >>>=20 >> >>>> "R5: The mapping protocol should allow for alternative=20 >redundant=20 >> >>>> sources of mapping information, possibly of different=20 >degrees of=20 >> >>>> currency. >> >>>> >> >>>> "Motivation: This provides the possibility of having available=20 >> >>>> alternative sources of mapping information when the normal >> >>source is >> >>>> unavailable or unreachable, without specifying the means >> by which >> >>>> the alternative source is created or updated." >> >>>> >> >>>> I think this proposition has concrete implications for protocol=20 >> >>>> design, hence should be stated. >> >>>=20 >> >>>=20 >> >>> Well, I like this much better than the current version. =20 >> Perhaps a >> >>> slight tweak: >> >>>=20 >> >>> R5: The mapping protocol should not inhibit the deployment of=20 >> >>> alternative redundant sources of mapping information,=20 >possibly of=20 >> >>> different degrees of currency." >> >>>=20 >> >>> -andy >> >>>=20 >> >>>=20 >> >> >> >> >> >>_______________________________________________ >> >>Ecrit mailing list >> >>Ecrit@ietf.org >> >>https://www1.ietf.org/mailman/listinfo/ecrit >> >> >> > >> >_______________________________________________ >> >Ecrit mailing list >> >Ecrit@ietf.org >> >https://www1.ietf.org/mailman/listinfo/ecrit >> > >> >_______________________________________________ >> >Ecrit mailing list >> >Ecrit@ietf.org >> >https://www1.ietf.org/mailman/listinfo/ecrit >> > >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >>=20 > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 13 22:32:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQFNG-0004AK-IW; Thu, 13 Oct 2005 22:32:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQFNF-00049a-T3 for ecrit@megatron.ietf.org; Thu, 13 Oct 2005 22:32:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11057 for ; Thu, 13 Oct 2005 22:32:42 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQFXq-0003la-Pi for ecrit@ietf.org; Thu, 13 Oct 2005 22:43:45 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Thu, 13 Oct 2005 22:32:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Summary ecrit-requirements-00 section 6: Emergency Identifier Date: Thu, 13 Oct 2005 19:32:26 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A6575035484EE@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Summary ecrit-requirements-00 section 6: Emergency Identifier Thread-Index: AcXCxPOufPl+8lb7QxOvtScLhAjQIANjBLvQ From: "Roger Marshall" To: "Tom-PT Taylor" , "ECRIT" , "Henning Schulzrinne" X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Tom: Subj: Section 6, Emergency Identifier Thanks for your extensive input. Quite a lot different here now. Please see my comments inline.=20 >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Tom-PT Taylor >Sent: Monday, September 26, 2005 11:03 AM >To: ECRIT; Henning Schulzrinne >Subject: [Ecrit] Summary ecrit-requirements-00 section=20 >6:Emergency Identifier > >Just to summarize my understanding of our discussion last=20 >week, here's how a rewritten section 6 would look: > >-------- > >A1a: Universal emergency indication -- setup. For each=20 >signalling protocol that can be used in an emergency call, it=20 >must be possible to indicate, as a standard part of the=20 >protocol within the call-initiating message, that this is an=20 >emergency call. > >Motivation: such an indication is necessary to trigger=20 >emergency handling including relaxation of authentication and=20 >authorization procedures, access to call features otherwise=20 >not available, and routing toward the PSAP including mapping=20 >from location when required. Slight rewording of the requirement, (motivation left alone), from=20 how you have it, A1a: Universal emergency indication - call setup. For each=20 signaling protocol that is used to set up an emergency call,=20 there MUST be an indication, as a standard part of the message=20 protocol, that it is an emergency call. > >A1a+: The emergency indication is required beyond the point of mapping. > >Motivation: there is a continuing need for a trigger for=20 >emergency handling procedures in ESRPs beyond the point of mapping. This is probably a good idea. I have reformed this new requirement some, as follows: A1a+: Universal emergency indication - sustained. There MUST be retained,=20 (or supplied) an universal emergency indication as a standard part of the message=20 protocol all through call routing, even after the mapping protocol has been invoked. Motivation: there is a continuing need for a trigger for=20 emergency handling procedures in ESRPs beyond the point of mapping. > >--------------- > >A1b: original formulation is seen as redundant, DELETED. New=20 >requirement: > >A1b': the mapping protocol also needs an emergency indication. > >Motivation: this allows reuse of the mapping protocol and the=20 >mapping servers for non-emergency purposes. Please see my response to Henning's subsequent email on this one. > >-------- > > > >A1c: emergency marking. Any device in the signalling path=20 >that recognizes by some means that the signalling is=20 >associated with an emergency call MUST add the emergency=20 >indication called for in A1a to the signalling before forwarding it. > >Motivation: this ensures proper handling as an emergency call=20 >by downstream elements that may not recognize, for example, a=20 >local variant of a logical emergency address (see requirement A4+). Above requirement accepted as is.included with minor editing changes as follows: A1c: Emergency marking. Any device in the signaling path=20 that recognizes by some means that the signaling is=20 associated with an emergency call MUST add the emergency=20 indication called for in A1a to the signaling before forwarding it. Motivation: Marking ensures proper handling as an emergency call=20 by downstream elements that may not recognize, for example, a=20 local variant of a logical emergency address (see requirement A4+). > >A1c+: User agents, proxies, and other network elements that may process >signalling associated with emergency calls should be=20 >configured to recognize a reasonable repertoire of logical=20 >emergency addresses (described in requirement A4+ below) as a=20 >means to trigger emergency marking. Because emergency numbers=20 >from one region may have different uses in another, it is best=20 >if a network entity is able to place a call in the context of=20 >its point of origin before using a non-local logical emergency=20 >address as the basis for emergency marking. > >Motivation: Out-of-region logical emergency addresses may be=20 >emitted by an user terminal that has been imported into a=20 >given region but is configured for a different home region. =20 >The user may have dialled a familiar emergency number rather=20 >than the local one. Signalling may have crossed regional=20 >boundaries before being processed by a network entity capable=20 >of performing emergency marking and other emergency=20 >processing. All of these cases must be handled as emergency=20 >calls if at > possible. Condensed above requirement into the following requirement and motivation text: A1c+. Network Element Initiated Marking: User=20 agents, proxies, and other network elements that process signaling=20 associated with emergency calls SHOULD be configured to recognize a=20 reasonable selection of logical emergency identifiers (described in=20 requirement A4+ below) as a means to initiate emergency marking. Motivation: Since user devices roam, emergency identifiers may vary=20 from region to region. It is therefore important that a network entity be=20 able to perform mapping and/or call routing within the context of its own=20 point of origin rather than relying on non-local logical emergency=20 identifiers as the only basis for emergency marking of calls. > >----------- > >A3. Prevention of fraud. >A call identified as an emergency call or marked as such in=20 >accordance with requirement A1c MUST be routed to a PSAP. > >Motivation: this prevents use of the emergency call indication=20 >to gain access to call features or authentication override for=20 >non-emergency purposes. Changed as proposed within draft. > >------------ > >A4+: Logical emergency addresses. For each signalling protocol that can >be used in an emergency call, reserved addresses should be=20 >available to use in place of an emergency address prior to the=20 >point in the signalling path where mapping is done. The=20 >appropriate logical emergency address may be based on local=20 >convention (e.g., 911, 112, ..., in form appropriate to the=20 >signalling protocol). However, it is desirable to have a=20 >universal logical emergency address or a set of them=20 >identifying specific emergency services. > >Motivation: Any signalling protocol requires the use of some=20 >address to indicate the called party, and the user terminal=20 >may lack the capability to determine the actual PSAP address. =20 >The use of local conventions may be required as a transition=20 >mechanism. However, such use complicates international=20 >movement of the user terminal, and evolution to a standardized=20 >universal logical emergency address or set of addresses is preferable. Condensed the text above to be included in draft as follows: A4+: Emergency Identifier Replacement. For each signaling=20 protocol that can be used in an emergency call, reserved=20 addresses SHOULD be allowed to replace the original=20 emergency identifier, based on local conventions, regulations,=20 Or preference (in the case of an enterprise, for example).=20 Motivation: Any signalling protocol requires the use of some=20 address to indicate the called party, and the user terminal=20 may lack the capability to determine the actual PSAP address. =20 The use of local conventions may be required as a transition=20 mechanism. Note: Such use complicates international=20 movement of the user terminal, and evolution to a standardized=20 universal logical emergency identifier or set of identifiers is preferable. > >A4. Minimal configuration. Any local logical emergency=20 >addresses should be configured into user terminals=20 >automatically, without user intervention. > >Motivation: a new user terminal "unofficially imported" into=20 >an organization from elsewhere should have the same emergency=20 >capabilities as one officially installed. Again, please see my response to Henning's subsequent email on this one. Roger Marshall > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 13 22:33:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQFOO-0004Hr-Km; Thu, 13 Oct 2005 22:33:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQFON-0004Hd-67 for ecrit@megatron.ietf.org; Thu, 13 Oct 2005 22:33:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11112 for ; Thu, 13 Oct 2005 22:33:51 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQFZ0-0003nj-GO for ecrit@ietf.org; Thu, 13 Oct 2005 22:44:54 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Thu, 13 Oct 2005 22:33:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Re: Summary ecrit-requirements-00 section 6: Emergency Identifier Date: Thu, 13 Oct 2005 19:33:44 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A6575035484EF@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Re: Summary ecrit-requirements-00 section 6: Emergency Identifier Thread-Index: AcXDAB+Utk1j3jPRTP25c/T1amqGGwNR90MQ From: "Roger Marshall" To: "Henning Schulzrinne" , "Tom-PT Taylor" X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Henning: Subj: continuation of Tom's initial comments to the requirements draft, section 6 - Emergency identifier. See comments in-line. =20 >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Henning Schulzrinne >Sent: Monday, September 26, 2005 6:07 PM >To: Tom-PT Taylor >Cc: ECRIT >Subject: [Ecrit] Re: Summary ecrit-requirements-00 section=20 >6:Emergency Identifier > >Some comments inline. > >Tom-PT Taylor wrote: > >>=20 >> A1b: original formulation is seen as redundant, DELETED. =20 >New requirement: >>=20 >> A1b': the mapping protocol also needs an emergency indication. >>=20 >> Motivation: this allows reuse of the mapping protocol and=20 >the mapping=20 >> servers for non-emergency purposes. > >To avoid having two requirements that are essentially=20 >supersets of one another, we might simply say that it needs to=20 >indicate the emergency service (such as "fire") in=20 >jurisdictions where more than a single emergency service=20 >contact is provided. I agree that the original 1a and 1b were mostly duplicative, so in trying to pull out what is suggested here by Henning, I offer the following replacement requirement for the original 1b: A1b. Universal Identifier Resolution:"> Where multiple=20 emergency service types exist, it MUST be possible to treat each=20 emergency identifier separately, based on the specific type of=20 emergency help requested. Motivation: Some jurisdictions may have multiple types of emergency=20 services available at the same level, (e.g. fire, police, ambulance), in which case it is important that any one could be selected directly. Is this close to what you were suggesting? > > > >> A4. Minimal configuration. Any local logical emergency addresses=20 >> should be configured into user terminals automatically,=20 >without user intervention. >>=20 >> Motivation: a new user terminal "unofficially imported" into an=20 >> organization from elsewhere should have the same emergency=20 >> capabilities as one officially installed. I'm not sure what the impact of the proposed change here is. Other than we've already relegated the term "address" to not much more than IP address (now using identifier), I don't think that "local logical..." sheds much light over "local...". > >I think one distinction getting a bit lost is between the=20 >digits or symbols dialed by a user placing an emergency call=20 >and the call signaling emitted. The configuration is only=20 >necessary for the digits/symbols, as then the device can=20 >automatically translate into the "logical identifier". By=20 >using examples such as 911, the distinction between dial=20 >strings and identifiers is getting blurred. We had lots of=20 >problem with that in the 2806bis discussion and it would be=20 >unhelpful to muddy the waters again. The example that I'm thinking of is either, A. 9, 1, 1 is translated in the device as: urn:sos.service.emergency Or B. [Help! Button] is translated in the device as: urn:sos.service.emergency Is this what you are referring to? Roger Marshall. > > >Btw, the discussion here addresses ECRIT charter item "A BCP=20 >describing how to identify a session set-up request is to an=20 >emergency response center". > >Henning > > > > > > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 13 22:46:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQFaI-0000Xr-4u; Thu, 13 Oct 2005 22:46:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQFaH-0000Xm-7s for ecrit@megatron.ietf.org; Thu, 13 Oct 2005 22:46:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11809 for ; Thu, 13 Oct 2005 22:46:09 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQFkt-00049U-ND for ecrit@ietf.org; Thu, 13 Oct 2005 22:57:12 -0400 Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net [141.153.174.94]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j9E2k7XD012235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 13 Oct 2005 22:46:10 -0400 (EDT) Message-ID: <434F1BEE.4020903@cs.columbia.edu> Date: Thu, 13 Oct 2005 22:46:06 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roger Marshall Subject: Re: [Ecrit] Re: Summary ecrit-requirements-00 section 6: Emergency Identifier References: <8C837214C95C864C9F34F3635C2A6575035484EF@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A6575035484EF@SEA-EXCHVS-2.telecomsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.2 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > A1b. Universal Identifier Resolution:"> Where multiple > emergency service types exist, it MUST be possible to treat each > emergency identifier separately, based on the specific type of > emergency help requested. > > Motivation: Some jurisdictions may have multiple types of emergency > services available at the same level, (e.g. fire, police, ambulance), in > > which case it is important that any one could be selected directly. > > Is this close to what you were suggesting? Close enough. > > The example that I'm thinking of is either, > > A. 9, 1, 1 is translated in the device as: > urn:sos.service.emergency > Or > B. [Help! Button] is translated in the device as: > urn:sos.service.emergency > > Is this what you are referring to? > Yes. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 14 14:53:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQUfy-00040a-4W; Fri, 14 Oct 2005 14:53:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQUfw-00040Q-Jr for ecrit@megatron.ietf.org; Fri, 14 Oct 2005 14:53:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04920 for ; Fri, 14 Oct 2005 14:52:58 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQUqh-0006PM-5f for ecrit@ietf.org; Fri, 14 Oct 2005 15:04:12 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Fri, 14 Oct 2005 14:52:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Comments on ecrit-requirements-00 section 5: L6 and L29 Date: Fri, 14 Oct 2005 11:50:31 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A6575035488A7@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Comments on ecrit-requirements-00 section 5: L6 and L29 Thread-Index: AcW+wfZaYZpN/be9TjOH6L+ShH6/JQSJKXlg From: "Roger Marshall" To: "Tom-PT Taylor" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Tom: Subj: ECRIT requirements comments, Section 5 Thanks for your input to these. Please see my responses in-line. >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Tom-PT Taylor >Sent: Wednesday, September 21, 2005 8:30 AM >To: ecrit@ietf.org >Subject: [Ecrit] Comments on ecrit-requirements-00 section 5:=20 >L6 and L29 > >L6: the "motivation" is really just a definition, and there is=20 >a better definition in the terminology section. I think the=20 >real motivation is to provide opportunity to improve the=20 >accuracy of the routing process and to speed emergency call=20 >setup. Actual text: > >"Motivation: this provides the opportunity to help assure the=20 >accuracy of routing of emergency calls, and avoid delays=20 >during emergency call setup due to invalid locations." Makes sense. New Motivation restated (some additional rewording)=20 along with the requirement. Note: "civic address" changed=20 to "civic location" (this has been done throughout draft): L6. Validation of civic location: It MUST be possible to=20 validate an civic location prior to its use in an actual=20 emergency call. Motivation: Location validation provides an opportunity to=20 help assure whether successful mapping to the appropriate=20 PSAP will likely occur. Validation may also help to avoid=20 delays during emergency call setup due to invalid locations. > > >L29: >(1) It would be good if this followed immediately after L6,=20 >since the two requirements are closely related. > >(2) The motivation is too broad relative to the requirement. =20 >I'd suggest something like the following: > >"Motivation: failures of routine procedures or special=20 >circumstances will inevitably result in the occasional=20 >presentation of non-validated and in some cases invalid=20 >locations. The emergency routing system must provide a=20 >reasonable response to them." I think this motivation misses the point, why validation must not be required. I've taken a stab at a reworded motivation part to L29 (requirement restated for context): L29. Validation of a civic location MUST NOT be=20 required to enable any feature that is part of the emergency call=20 process. Motivation: In some cases, (based on a variety of factors),=20 a civic location may not be considered valid. This fact should=20 not result in the call being dropped or rejected by any entity=20 along the signaling path to the PSAP. Also, I'm ok with shifting requirement L29 up, to immediately follow L6 as suggested. Roger Marshall > >Tom Taylor > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Oct 15 15:59:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQsBV-0003NU-Li; Sat, 15 Oct 2005 15:59:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQsBT-0003NM-1E for ecrit@megatron.ietf.org; Sat, 15 Oct 2005 15:59:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24871 for ; Sat, 15 Oct 2005 15:59:04 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQsMR-0003Z3-2S for ecrit@ietf.org; Sat, 15 Oct 2005 16:10:32 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j9FJuDH04505; Sat, 15 Oct 2005 15:56:13 -0400 (EDT) Received: from zcarhxp0.corp.nortel.com ([47.129.230.91]) by zrc2hxm0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 15 Oct 2005 14:58:46 -0500 Received: from [127.0.0.1] ([47.9.16.149] RDNS failed) by zcarhxp0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 15 Oct 2005 15:58:45 -0400 Message-ID: <43515F73.1070408@nortel.com> Date: Sat, 15 Oct 2005 15:58:43 -0400 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roger Marshall Subject: Re: [Ecrit] Re: Summary ecrit-requirements-00 section 6: Emergency Identifier References: <8C837214C95C864C9F34F3635C2A6575035484EF@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A6575035484EF@SEA-EXCHVS-2.telecomsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Oct 2005 19:58:45.0674 (UTC) FILETIME=[D9BBA0A0:01C5D1C2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Roger, I'm a bit concerned with what you say below about the limited scope of the term "emergency address". We need a term that covers URIs as well as IP addresses, at the very least. I thought "emergency address" was it, according to the definition in the Terminology section. Roger Marshall wrote: > Henning: > Subj: continuation of Tom's initial comments to the requirements draft, > section 6 - Emergency identifier. > > See comments in-line. > ... >> >>>A4. Minimal configuration. Any local logical emergency addresses >>>should be configured into user terminals automatically, >> >>without user intervention. >> >>>Motivation: a new user terminal "unofficially imported" into an >>>organization from elsewhere should have the same emergency >>>capabilities as one officially installed. > > > > > I'm not sure what the impact of the proposed change here is. Other than > we've already relegated the term "address" to not much more than IP > address (now using identifier), I don't think that "local logical..." > sheds much light over "local...". > ... _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 17 03:44:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERPfP-00077u-Kv; Mon, 17 Oct 2005 03:44:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERPfO-00077j-Ed for ecrit@megatron.ietf.org; Mon, 17 Oct 2005 03:44:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22692 for ; Mon, 17 Oct 2005 03:44:11 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERPqg-0003tm-CA for ecrit@ietf.org; Mon, 17 Oct 2005 03:55:58 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j9H7fP409568 for ; Mon, 17 Oct 2005 03:41:25 -0400 (EDT) Received: from zcarhxp0.corp.nortel.com ([47.129.230.91]) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Oct 2005 03:43:59 -0400 Received: from [127.0.0.1] ([47.152.168.111] RDNS failed) by zcarhxp0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Oct 2005 03:43:56 -0400 Message-ID: <43535622.5090109@nortel.com> Date: Mon, 17 Oct 2005 16:43:30 +0900 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2005 07:43:58.0095 (UTC) FILETIME=[885071F0:01C5D2EE] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Subject: [Ecrit] Final comments on ecrit-requirements-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I didn't realize I was so close to finishing, or I would have put this together at the last stopover. The page count was misleading ... General remark: It's probably time to get rid of the old requirement numbers. I think the ordering and number of requirements will be fairly stable from now on, and the old numbering has been thoroughly messed up in some sections. I31 and I31b: I'd suggest I31 should come before I4, and I31b is in the same group. I39 doesn't make any sense in the general context of call setup. Surely it doesn't imply that a call already set up will suddenly be yanked off to another PSAP based on more accurate data. I'd suggest the relevant aspect is covered by I42, and the rest is a matter of what is presented to the call taker. ------------- On the performance objectives: You've made a start, but we have to take it a bit further. An old teletraffic engineering trick is to assume that probabilities along a path are additive. This is a reasonable assumption for low probabilities. To show how it applies here: You've declared a total latency to ring-tone objective with a set of probabilities for given delays. BTW you've assumed a normal distribution of delay probabilities,likely not the true model, but that means one of your objectives will be more binding than the others. Let's take the 8-second delay probability (1% more than 8s) as a working example. We have to allocate that 1% to different components of the total setup process. Since we're concentrating on the mapping protocol at the moment, one possible allocation is: - probability of delay > 8s within the mapping operation: 0.1% - probability of delay >8 s within all other segments of call setup: 0.9% Note the implicit assumption that there is negligible probability that neither segment takes as much as 8 seconds but the sum is > 8 seconds. That isn't really the case, but the overall results will behave as if it were at low probabilities. That said, the appropriate allocation is a matter of economics. We have to model each subsystem and determine how cost varies with the allocated probability. That typically involves looking at the economics of hypothetical reference connections. Looks like a good exercise for a student. Meantime, as a starting point, an allocation of 0.1% probability that the mapping process will take more than 8 seconds feels about right to me. That's what I'd suggest you add to your "latency to ringtone" objective. As for "latency to operator": the difference from "latency to ringtone" is partly media propagation time, but mostly a matter of PSAP staffing levels. Neither relates to performance of the mapping operation, so I'd suggest it is redundant in our context. Tom Taylor _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 17 08:48:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERUPb-0006Nu-Pb; Mon, 17 Oct 2005 08:48:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERUPa-0006No-Oj for ecrit@megatron.ietf.org; Mon, 17 Oct 2005 08:48:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09894 for ; Mon, 17 Oct 2005 08:48:11 -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.43) id 1ERUau-0004pz-Ug for ecrit@ietf.org; Mon, 17 Oct 2005 09:00:01 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 17 Oct 2005 05:48:08 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9HCm5Jh010805; Mon, 17 Oct 2005 05:48:06 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Oct 2005 05:48:05 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Oct 2005 05:48:05 -0700 From: "Marc Linsner" To: "'Winterbottom, James'" , "'Tom-PT Taylor'" Subject: RE: [Ecrit] Proposed Requirement Date: Mon, 17 Oct 2005 08:48:05 -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: AcW9I8rqnUuW1BbARweSYy/NHW97fQBFOG6ABTdF/7A= In-Reply-To: Message-ID: X-OriginalArrivalTime: 17 Oct 2005 12:48:05.0257 (UTC) FILETIME=[04786790:01C5D319] X-Spam-Score: 1.1 (+) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org James, This may be more of an argument for geopriv as the motivation stated for this requirement, IMO, lines up with RFC3693. I'm not sure I agree (nor does RFC3693) that all lcms servers should have 'carte blanche' access to anyone's location data on every LIS globally. Of course, the rulemaker could have a rule that '*.lcms.net' (or similar) has all access, which I see as unlikely. I do see the entity in front (in terms of making an emergency call) of the lcms server as being closer to the rulemaker and more likely to have access to the target's location data (i.e. ability to resolve location-by-reference), since this entity is most likely to be the rulemaker's contracted/controlled/well-known VoIP provider (in the case of emergency voice calls). Hence, I believe that only known-to-the-rulemaker entities should be resolving location-by-reference into location-by-value. Thoughts? -Marc- > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Tuesday, September 20, 2005 7:18 PM > To: Tom-PT Taylor; Marc Linsner > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Proposed Requirement > > I could not disagree more with this requirement! > > The Mapping service by its very virtue of providing > destination routing information based on location grants it > the very trust that is being argued below that it does not > have. Further to this, the mapping functions are in most > cases likely to be in the best position to have this trust > placed on them. I see the argument raised for having this > requirement as being moot. > > A mapping function MUST be able to accept either a > location-by-reference (preferred in the mobile case), or > alternatively by-value, preferably if the source can be verified. > > Cheers > James > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > Of > > Tom-PT Taylor > > Sent: Tuesday, 20 September 2005 12:06 AM > > To: Marc Linsner > > Cc: ecrit@ietf.org > > Subject: Re: [Ecrit] Proposed Requirement > > > > I like it. > > > > Marc Linsner wrote: > > > A proposed new requirement for the 'almost finished' req. > draft..... > > > > > > Requirement: The ecrit mechanism will only deal with location data > in > > value > > > form, any location by-reference or location-key MUST be > resolved to > a > > > location by-value prior to query submission to the > mapping database. > > > > > > Motivation: It cannot be expected that the entities > considered to be > > 'the > > > mapping database' (accepting the queries and returning a > resolution) > of > > the > > > location mapping-to-uri function be part of any trust or > authentication > > > mechanism that may be required to resolve location > > > by-reference/location-key. > > > > > > > > > This requirement spurs the need to define location by-reference, > > > location-key and location by-value in section 2 - Terminology. > > Hence.... > > > > > > Location by-reference: A URI that when accessed by an authorized > entity > > will > > > yield the location of the end-point to which the reference is > > associated. > > > > > > Location-Key: A mechanism used to provide a reference to > a location. > > This > > > may be a URI, a URL or some other kind of identifier. > > > > > > Location by-value: The location data in it's native form (see > location). > > > > > > > > > Fire-away, > > > > > > -Marc- > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 17 10:40:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERWAW-0008Gz-PP; Mon, 17 Oct 2005 10:40:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERWAV-0008Ge-23 for ecrit@megatron.ietf.org; Mon, 17 Oct 2005 10:40:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16111 for ; Mon, 17 Oct 2005 10:40:41 -0400 (EDT) Received: from dnsmx1rrc.telcordia.com ([128.96.20.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERWLn-00088D-Kh for ecrit@ietf.org; Mon, 17 Oct 2005 10:52:32 -0400 Received: from rrc-its-ieg02.cc.telcordia.com (rrc-its-ieg02.cc.telcordia.com [128.96.109.3]) by dnsmx1rrc.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id j9HEeXE27762 for ; Mon, 17 Oct 2005 10:40:34 -0400 (EDT) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by rrc-its-ieg02.cc.telcordia.com (SMSSMTP 4.0.5.66) with SMTP id M2005101710403018451 for ; Mon, 17 Oct 2005 10:40:30 -0400 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 17 Oct 2005 10:36:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 17 Oct 2005 10:38:42 -0400 Message-ID: Thread-Topic: Validation in LUMP Proposal Thread-Index: AcXTKLflQt0SlXywTNee+hqzdW4Oyw== From: "Haluska, John J" To: X-OriginalArrivalTime: 17 Oct 2005 14:36:45.0261 (UTC) FILETIME=[32B20FD0:01C5D328] X-Spam-Score: 0.2 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Subject: [Ecrit] Validation in LUMP Proposal X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0999239640==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0999239640== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D328.7855D4C3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D328.7855D4C3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have a question on the LUMP proposal - the draft states that validation is supported, but it does not indicate how it is supported. Is there an explicit method for performing validation? Or is it implicitly performed when a query is made? If the latter is true, would it be fair to say this can be generalized to apply to all of the mapping proposals? =20 John Haluska =20 =20 ------_=_NextPart_001_01C5D328.7855D4C3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have a question on the  LUMP proposal – = the draft states that validation is supported, but it does not indicate how it is supported. Is there an explicit method for performing validation? Or is = it implicitly performed when a query is  made? If the latter is true, = would it be fair to say this can be generalized to apply to all of the mapping proposals?

 

John Haluska

 

 

=00 ------_=_NextPart_001_01C5D328.7855D4C3-- --===============0999239640== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0999239640==-- From ecrit-bounces@ietf.org Mon Oct 17 19:32:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EReTK-0001z2-EV; Mon, 17 Oct 2005 19:32:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EReTJ-0001wu-DB for ecrit@megatron.ietf.org; Mon, 17 Oct 2005 19:32:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15695 for ; Mon, 17 Oct 2005 19:32:40 -0400 (EDT) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EReej-0008Jm-Fx for ecrit@ietf.org; Mon, 17 Oct 2005 19:44:37 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Oct 2005 18:32:33 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Mon, 17 Oct 2005 18:32:33 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Oct 2005 18:32:32 -0500 Message-ID: From: "Winterbottom, James" To: "Marc Linsner" , "Tom-PT Taylor" Date: Mon, 17 Oct 2005 18:32:30 -0500 Subject: RE: [Ecrit] Proposed Requirement MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 17 Oct 2005 23:32:32.0522 (UTC) FILETIME=[0BF4CEA0:01C5D373] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Proposed Requirement Thread-Index: AcW9I8rqnUuW1BbARweSYy/NHW97fQBFOG6ABTdF/7AAFtKu4A== X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Marc, I understand the argument, and I think that it is well put in that sense. If the VSP has to do the locationURI dereference and pass the location to the lcms then short of the VSP being a B2BUA and inserting the location into the SIP body, access to location from a PSAP will be required via the locationURI anyway. Do you see that the lcms are likely to be operated by the PSAPs, or at the very least have the services contracted to them by the PSAPs? If so then I don't see why the suggested authority can't be delegated in this situation. My point here to is that if you make a call and do not have a relationship with a VSP, it is likely that the only rule you can apply is to the lcms or PSAP. So I think that it is still necessary to allow the lcms to accept a location-by-reference in place of a location-by-value. Cheers James > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Monday, 17 October 2005 10:48 PM > To: Winterbottom, James; 'Tom-PT Taylor' > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Proposed Requirement >=20 > James, >=20 > This may be more of an argument for geopriv as the motivation stated for > this requirement, IMO, lines up with RFC3693. I'm not sure I agree (nor > does RFC3693) that all lcms servers should have 'carte blanche' access to > anyone's location data on every LIS globally. Of course, the rulemaker > could have a rule that '*.lcms.net' (or similar) has all access, which I > see > as unlikely. I do see the entity in front (in terms of making an > emergency > call) of the lcms server as being closer to the rulemaker and more likely > to > have access to the target's location data (i.e. ability to resolve > location-by-reference), since this entity is most likely to be the > rulemaker's contracted/controlled/well-known VoIP provider (in the case of > emergency voice calls). Hence, I believe that only known-to-the-rulemaker > entities should be resolving location-by-reference into location-by-value. >=20 > Thoughts? >=20 > -Marc- >=20 > > -----Original Message----- > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: Tuesday, September 20, 2005 7:18 PM > > To: Tom-PT Taylor; Marc Linsner > > Cc: ecrit@ietf.org > > Subject: RE: [Ecrit] Proposed Requirement > > > > I could not disagree more with this requirement! > > > > The Mapping service by its very virtue of providing > > destination routing information based on location grants it > > the very trust that is being argued below that it does not > > have. Further to this, the mapping functions are in most > > cases likely to be in the best position to have this trust > > placed on them. I see the argument raised for having this > > requirement as being moot. > > > > A mapping function MUST be able to accept either a > > location-by-reference (preferred in the mobile case), or > > alternatively by-value, preferably if the source can be verified. > > > > Cheers > > James > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of > > > Tom-PT Taylor > > > Sent: Tuesday, 20 September 2005 12:06 AM > > > To: Marc Linsner > > > Cc: ecrit@ietf.org > > > Subject: Re: [Ecrit] Proposed Requirement > > > > > > I like it. > > > > > > Marc Linsner wrote: > > > > A proposed new requirement for the 'almost finished' req. > > draft..... > > > > > > > > Requirement: The ecrit mechanism will only deal with location data > > in > > > value > > > > form, any location by-reference or location-key MUST be > > resolved to > > a > > > > location by-value prior to query submission to the > > mapping database. > > > > > > > > Motivation: It cannot be expected that the entities > > considered to be > > > 'the > > > > mapping database' (accepting the queries and returning a > > resolution) > > of > > > the > > > > location mapping-to-uri function be part of any trust or > > authentication > > > > mechanism that may be required to resolve location > > > > by-reference/location-key. > > > > > > > > > > > > This requirement spurs the need to define location by-reference, > > > > location-key and location by-value in section 2 - Terminology. > > > Hence.... > > > > > > > > Location by-reference: A URI that when accessed by an authorized > > entity > > > will > > > > yield the location of the end-point to which the reference is > > > associated. > > > > > > > > Location-Key: A mechanism used to provide a reference to > > a location. > > > This > > > > may be a URI, a URL or some other kind of identifier. > > > > > > > > Location by-value: The location data in it's native form (see > > location). > > > > > > > > > > > > Fire-away, > > > > > > > > -Marc- > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > -------------------------------------------------------------- > > ---------------------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > -------------------------------------------------------------- > > ---------------------------------- > > [mf2] ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 17 19:59:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERetZ-0005Gk-Ve; Mon, 17 Oct 2005 19:59:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERetY-0005Gf-JL for ecrit@megatron.ietf.org; Mon, 17 Oct 2005 19:59:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17177 for ; Mon, 17 Oct 2005 19:59:48 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERf4y-0000bh-Vf for ecrit@ietf.org; Mon, 17 Oct 2005 20:11:45 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Mon, 17 Oct 2005 19:59:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Final comments on ecrit-requirements-00 Date: Mon, 17 Oct 2005 16:59:36 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65750358A432@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Final comments on ecrit-requirements-00 Thread-Index: AcXS7znrze8rOupVR/e4DqGHCGGKNAAfiAgg From: "Roger Marshall" To: "Tom-PT Taylor" , "ECRIT" X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Tom: Thanks for these comments. See my responses in-line. >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Tom-PT Taylor >Sent: Monday, October 17, 2005 12:44 AM >To: ECRIT >Subject: [Ecrit] Final comments on ecrit-requirements-00 > >I didn't realize I was so close to finishing, or I would have=20 >put this together at the last stopover. The page count was=20 >misleading ... > >General remark: It's probably time to get rid of the old=20 >requirement numbers. I think the ordering and number of=20 >requirements will be fairly stable from now on, and the old=20 >numbering has been thoroughly messed up in some sections. > >I31 and I31b: I'd suggest I31 should come before I4, and I31b=20 >is in the same group. I will plan to do this on the next draft, unless there is an overwhelming outcry against. > >I39 doesn't make any sense in the general context of call=20 >setup. Surely it doesn't imply that a call already set up=20 >will suddenly be yanked off to another PSAP based on more=20 >accurate data. I'd suggest the relevant aspect is covered by=20 >I42, and the rest is a matter of what is presented to the call taker. I think you're right, that we should be clear as to what implications are stated within the motivation. I39 itself is general (a good thing). How's an update can be used, either during call signaling or afterward, I'd rather not address with this requirement.=20 I39. Location Updates: It SHOULD be possible to have updates of location. Proposed new motivation text: Motivation: Updated location information may have an impact on PSAP routing. In some cases it may be possible to redirect that call to a more appropriate PSAP (some device measurement techniques provide quick (i.e. early), but imprecise "first fix" location). > >------------- > >On the performance objectives: You've made a start, but we=20 >have to take it a bit further. An old teletraffic engineering=20 >trick is to assume that probabilities along a path are=20 >additive. This is a reasonable assumption for low=20 >probabilities. To show how it applies here: > >You've declared a total latency to ring-tone objective with a=20 >set of probabilities for given delays. BTW you've assumed a=20 >normal distribution of delay probabilities,likely not the true=20 >model, but that means one of your objectives will be more=20 >binding than the others. >Let's take the 8-second delay probability (1% more than 8s) as=20 >a working example. We have to allocate that 1% to different=20 >components of the total setup process. Since we're=20 >concentrating on the mapping protocol at the moment, one=20 >possible allocation is: > >- probability of delay > 8s within the mapping operation: 0.1% >- probability of delay >8 s within all other segments of call=20 >setup: 0.9% > >Note the implicit assumption that there is negligible=20 >probability that neither segment takes as much as 8 seconds=20 >but the sum is > 8 seconds. >That isn't really the case, but the overall results will=20 >behave as if it were at low probabilities. > >That said, the appropriate allocation is a matter of=20 >economics. We have to model each subsystem and determine how=20 >cost varies with the allocated probability. That typically=20 >involves looking at the economics of hypothetical reference=20 >connections. Looks like a good exercise for a student. > >Meantime, as a starting point, an allocation of 0.1%=20 >probability that the mapping process will take more than 8=20 >seconds feels about right to me. That's what I'd suggest you=20 >add to your "latency to ringtone" >objective. > >As for "latency to operator": the difference from "latency to ringtone" >is partly media propagation time, but mostly a matter of PSAP=20 >staffing levels. Neither relates to performance of the=20 >mapping operation, so I'd suggest it is redundant in our context. Tom, this idea of trying to specify this within this requirements draft was controversial at Paris, and is probably still so. More than anything else, though, I think you've pointed out that a lot more thought could be put into these numbers and how we think about comparitive performance. =20 Therefore, I propose to remove this performance section in the next draft. Is there agreement to this move? Roger Marshall > >Tom Taylor > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 17 20:10:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERf48-0000ih-LG; Mon, 17 Oct 2005 20:10:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERf46-0000iW-Qh for ecrit@megatron.ietf.org; Mon, 17 Oct 2005 20:10:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17807 for ; Mon, 17 Oct 2005 20:10:42 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERfFX-0000vv-EA for ecrit@ietf.org; Mon, 17 Oct 2005 20:22:39 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Mon, 17 Oct 2005 20:10:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Re: Summary ecrit-requirements-00 section 6: Emergency Identifier Date: Mon, 17 Oct 2005 17:10:40 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65750358A454@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Re: Summary ecrit-requirements-00 section 6: Emergency Identifier Thread-Index: AcXRwvfH5/9Gj2ZkTRq6fIsqFv5XbwBtAbYg From: "Roger Marshall" To: "Tom-PT Taylor" X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Tom: See comments in-line.=20 >-----Original Message----- >From: Tom-PT Taylor [mailto:taylor@nortel.com]=20 >Sent: Saturday, October 15, 2005 12:59 PM >To: Roger Marshall >Cc: Henning Schulzrinne; ECRIT >Subject: Re: [Ecrit] Re: Summary ecrit-requirements-00 section=20 >6: Emergency Identifier > >Roger, I'm a bit concerned with what you say below about the=20 >limited scope of the term "emergency address". We need a term=20 >that covers URIs as well as IP addresses, at the very least. =20 I guess I don't agree. We have the option to define "emergency address" to be one type of thing (uri), rather than more than one (uri & the uri's IP address). What's wrong with saying "emergency address" equates to a uri (some next leg of mapping (either mapping server, or PSAP), and "IP address" is what the uri gets translated into via DNS? Thanks. Roger Marshall. >I thought "emergency address" was it, according to the=20 >definition in the Terminology section. > >Roger Marshall wrote: >> Henning: >> Subj: continuation of Tom's initial comments to the requirements=20 >> draft, section 6 - Emergency identifier. >>=20 >> See comments in-line. >> =20 >... > >>> >>>>A4. Minimal configuration. Any local logical emergency addresses=20 >>>>should be configured into user terminals automatically, >>> >>>without user intervention. >>> >>>>Motivation: a new user terminal "unofficially imported" into an=20 >>>>organization from elsewhere should have the same emergency=20 >>>>capabilities as one officially installed. >>=20 >>=20 >>=20 >>=20 >> I'm not sure what the impact of the proposed change here is. Other=20 >> than we've already relegated the term "address" to not much=20 >more than=20 >> IP address (now using identifier), I don't think that "local=20 >logical..." >> sheds much light over "local...". >>=20 >... > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 18 08:14:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERqMg-0001td-D7; Tue, 18 Oct 2005 08:14:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERqMe-0001tX-FP for ecrit@megatron.ietf.org; Tue, 18 Oct 2005 08:14:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25855 for ; Tue, 18 Oct 2005 08:14:35 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERqYA-0003HO-EH for ecrit@ietf.org; Tue, 18 Oct 2005 08:26:39 -0400 Received: from zctfhxm1.corp.nortel.com (zctfhxm1.corp.nortel.com [47.164.129.157]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9ICEUp22654; Tue, 18 Oct 2005 08:14:31 -0400 (EDT) Received: from zcarhxp0.corp.nortel.com ([47.129.230.91]) by zctfhxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Oct 2005 14:13:36 +0200 Received: from [127.0.0.1] ([47.152.168.23] RDNS failed) by zcarhxp0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Oct 2005 08:13:33 -0400 Message-ID: <4354E6DF.4050509@nortel.com> Date: Tue, 18 Oct 2005 21:13:19 +0900 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roger Marshall Subject: Re: [Ecrit] Re: Summary ecrit-requirements-00 section 6: Emergency Identifier References: <8C837214C95C864C9F34F3635C2A65750358A454@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A65750358A454@SEA-EXCHVS-2.telecomsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Oct 2005 12:13:34.0392 (UTC) FILETIME=[5C8D3B80:01C5D3DD] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I'm happy -- I just wanted a term covering URI. I misunderstood something you said to suggest we had no term for URI. I said "URI or IP address" just to accommodate both of us. Roger Marshall wrote: ... > > I guess I don't agree. We have the option to define "emergency address" > to be one type of thing (uri), rather than more than one (uri & the > uri's IP address). What's wrong with saying "emergency address" equates > to a uri (some next leg of mapping (either mapping server, or PSAP), and > "IP address" is what the uri gets translated into via DNS? > > Thanks. > > Roger Marshall. > > >>I thought "emergency address" was it, according to the >>definition in the Terminology section. >> >>Roger Marshall wrote: >> >>>Henning: >>>Subj: continuation of Tom's initial comments to the requirements >>>draft, section 6 - Emergency identifier. >>> >>>See comments in-line. >>> >> >>... >> >> >>>>>A4. Minimal configuration. Any local logical emergency addresses >>>>>should be configured into user terminals automatically, >>>> >>>>without user intervention. >>>> >>>> >>>>>Motivation: a new user terminal "unofficially imported" into an >>>>>organization from elsewhere should have the same emergency >>>>>capabilities as one officially installed. >>> >>> >>> >>> >>>I'm not sure what the impact of the proposed change here is. Other >>>than we've already relegated the term "address" to not much >> >>more than >> >>>IP address (now using identifier), I don't think that "local >> >>logical..." >> >>>sheds much light over "local...". >>> >> >>... >> >> > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 18 08:14:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERqMJ-0001se-FD; Tue, 18 Oct 2005 08:14:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERqMF-0001s2-P8 for ecrit@megatron.ietf.org; Tue, 18 Oct 2005 08:14:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25837 for ; Tue, 18 Oct 2005 08:14:10 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERqXj-0003GV-VO for ecrit@ietf.org; Tue, 18 Oct 2005 08:26:14 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j9ICBHF12492; Tue, 18 Oct 2005 08:11:18 -0400 (EDT) Received: from zcarhxp0.corp.nortel.com ([47.129.230.91]) by zcarhxm0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Oct 2005 08:13:49 -0400 Received: from [127.0.0.1] ([47.152.168.23] RDNS failed) by zcarhxp0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Oct 2005 08:13:48 -0400 Message-ID: <4354E6F3.5030905@nortel.com> Date: Tue, 18 Oct 2005 21:13:39 +0900 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roger Marshall Subject: Re: [Ecrit] Final comments on ecrit-requirements-00 References: <8C837214C95C864C9F34F3635C2A65750358A432@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A65750358A432@SEA-EXCHVS-2.telecomsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Oct 2005 12:13:48.0954 (UTC) FILETIME=[653B37A0:01C5D3DD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Sorry, I still don't see how a location update can affect call routing, unless you are saying the setup should wait several seconds in case an update comes along. Unless that is what you mean, I39 is irrelevant to the routing process -- any location update will come after setup has been launched. Roger Marshall wrote: ... > > >>I39 doesn't make any sense in the general context of call >>setup. Surely it doesn't imply that a call already set up >>will suddenly be yanked off to another PSAP based on more >>accurate data. I'd suggest the relevant aspect is covered by >>I42, and the rest is a matter of what is presented to the call taker. > > > I think you're right, that we should be clear as to what implications > are stated within the motivation. I39 itself is general (a good thing). > How's an update can be used, either during call signaling or afterward, > I'd rather not address with this requirement. > > I39. Location Updates: It SHOULD be possible to have updates of > location. > > Proposed new motivation text: > > Motivation: Updated location information may have an impact on PSAP > routing. In some cases it may be possible to redirect that call to a > more appropriate PSAP (some device measurement techniques provide quick > (i.e. early), but imprecise "first fix" location). > > ... _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 18 09:28:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERrVp-0001Jl-V4; Tue, 18 Oct 2005 09:28:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERrVo-0001Jd-0Q for ecrit@megatron.ietf.org; Tue, 18 Oct 2005 09:28:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29713 for ; Tue, 18 Oct 2005 09:28:08 -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.43) id 1ERrhL-0005BC-6N for ecrit@ietf.org; Tue, 18 Oct 2005 09:40:11 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 18 Oct 2005 06:28:06 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9IDRiut011442; Tue, 18 Oct 2005 06:28:04 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Oct 2005 06:28:03 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Oct 2005 06:28:02 -0700 From: "Marc Linsner" To: "'Winterbottom, James'" , "'Tom-PT Taylor'" Subject: RE: [Ecrit] Proposed Requirement Date: Tue, 18 Oct 2005 09:28: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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcW9I8rqnUuW1BbARweSYy/NHW97fQBFOG6ABTdF/7AAFtKu4AAckN7Q In-Reply-To: Message-ID: X-OriginalArrivalTime: 18 Oct 2005 13:28:02.0327 (UTC) FILETIME=[C3A60270:01C5D3E7] X-Spam-Score: 1.1 (+) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org James, I believe we need to view the VSP, the LCMS service, and the PSAP as three separate entities with no relationship between them. I also agree with you that in *some* cases, the PSAP will be the entity that operates the LCMS, but from an architectual point of view, I don't believe we should depend on that in 100% of the cases. Therefore, we cannot make assumptions that privacy rules, as determined by the rule-maker with respect to a PSAP, can be extended to the LCMS service. I believe it's reasonable to view the LCMS service simply as an 'aid' to the session initiation process, similar to a 'dial plan'. With this view, the LCMS service will simply match location data to a URI, and will not be a true Location Recipient as defined in RFC3693 (no user identified, etc.). This obviously needs further discussion within the GeoPriv realm as we work through the ecrit protocol. So, dereference any location-by-reference prior to submitting to the LCMS service, the protocol is easy, quick, clean and covers all cases. Thanks, -Marc- > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Monday, October 17, 2005 7:33 PM > To: Marc Linsner; Tom-PT Taylor > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Proposed Requirement > > Hi Marc, > > I understand the argument, and I think that it is well put in > that sense. > If the VSP has to do the locationURI dereference and pass the > location to the lcms then short of the VSP being a B2BUA and > inserting the location into the SIP body, access to location > from a PSAP will be required via the locationURI anyway. > > Do you see that the lcms are likely to be operated by the > PSAPs, or at the very least have the services contracted to > them by the PSAPs? If so then I don't see why the suggested > authority can't be delegated in this situation. My point here > to is that if you make a call and do not have a relationship > with a VSP, it is likely that the only rule you can apply is > to the lcms or PSAP. So I think that it is still necessary to > allow the lcms to accept a location-by-reference in place of > a location-by-value. > > > Cheers > James > > > -----Original Message----- > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > Sent: Monday, 17 October 2005 10:48 PM > > To: Winterbottom, James; 'Tom-PT Taylor' > > Cc: ecrit@ietf.org > > Subject: RE: [Ecrit] Proposed Requirement > > > > James, > > > > This may be more of an argument for geopriv as the motivation stated > for > > this requirement, IMO, lines up with RFC3693. I'm not sure I agree > (nor > > does RFC3693) that all lcms servers should have 'carte > blanche' access > to > > anyone's location data on every LIS globally. Of course, the > rulemaker > > could have a rule that '*.lcms.net' (or similar) has all > access, which > I > > see > > as unlikely. I do see the entity in front (in terms of making an > > emergency > > call) of the lcms server as being closer to the rulemaker and more > likely > > to > > have access to the target's location data (i.e. ability to resolve > > location-by-reference), since this entity is most likely to be the > > rulemaker's contracted/controlled/well-known VoIP provider (in the > case of > > emergency voice calls). Hence, I believe that only > known-to-the-rulemaker > > entities should be resolving location-by-reference into > location-by-value. > > > > Thoughts? > > > > -Marc- > > > > > -----Original Message----- > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: Tuesday, September 20, 2005 7:18 PM > > > To: Tom-PT Taylor; Marc Linsner > > > Cc: ecrit@ietf.org > > > Subject: RE: [Ecrit] Proposed Requirement > > > > > > I could not disagree more with this requirement! > > > > > > The Mapping service by its very virtue of providing destination > > > routing information based on location grants it the very > trust that > > > is being argued below that it does not have. Further to this, the > > > mapping functions are in most cases likely to be in the best > > > position to have this trust placed on them. I see the argument > > > raised for having this requirement as being moot. > > > > > > A mapping function MUST be able to accept either a > > > location-by-reference (preferred in the mobile case), or > > > alternatively by-value, preferably if the source can be verified. > > > > > > Cheers > > > James > > > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On Behalf Of > > > > Tom-PT Taylor > > > > Sent: Tuesday, 20 September 2005 12:06 AM > > > > To: Marc Linsner > > > > Cc: ecrit@ietf.org > > > > Subject: Re: [Ecrit] Proposed Requirement > > > > > > > > I like it. > > > > > > > > Marc Linsner wrote: > > > > > A proposed new requirement for the 'almost finished' req. > > > draft..... > > > > > > > > > > Requirement: The ecrit mechanism will only deal with location > data > > > in > > > > value > > > > > form, any location by-reference or location-key MUST be > > > resolved to > > > a > > > > > location by-value prior to query submission to the > > > mapping database. > > > > > > > > > > Motivation: It cannot be expected that the entities > > > considered to be > > > > 'the > > > > > mapping database' (accepting the queries and returning a > > > resolution) > > > of > > > > the > > > > > location mapping-to-uri function be part of any trust or > > > authentication > > > > > mechanism that may be required to resolve location > > > > > by-reference/location-key. > > > > > > > > > > > > > > > This requirement spurs the need to define location > by-reference, > > > > > location-key and location by-value in section 2 - Terminology. > > > > Hence.... > > > > > > > > > > Location by-reference: A URI that when accessed by an > authorized > > > entity > > > > will > > > > > yield the location of the end-point to which the reference is > > > > associated. > > > > > > > > > > Location-Key: A mechanism used to provide a reference to > > > a location. > > > > This > > > > > may be a URI, a URL or some other kind of identifier. > > > > > > > > > > Location by-value: The location data in it's native form (see > > > location). > > > > > > > > > > > > > > > Fire-away, > > > > > > > > > > -Marc- > > > > > > > > > > _______________________________________________ > > > > > Ecrit mailing list > > > > > Ecrit@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > -------------------------------------------------------------- > > > ---------------------------------- > > > This message is for the designated recipient only and may contain > > > privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized > use of this > > > email is prohibited. > > > -------------------------------------------------------------- > > > ---------------------------------- > > > [mf2] > > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 18 10:38:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERscB-0002UU-VD; Tue, 18 Oct 2005 10:38:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERscA-0002UL-6y for ecrit@megatron.ietf.org; Tue, 18 Oct 2005 10:38:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04502 for ; Tue, 18 Oct 2005 10:38:46 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERsnh-0007R5-CZ for ecrit@ietf.org; Tue, 18 Oct 2005 10:50:50 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Tue, 18 Oct 2005 10:38:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Final comments on ecrit-requirements-00 Date: Tue, 18 Oct 2005 07:38:33 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65750358A56E@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Final comments on ecrit-requirements-00 Thread-Index: AcXT3Xg6iDIaPvhYQbC6ji+1Aj8S9wAEoRjA From: "Roger Marshall" To: "Tom-PT Taylor" X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Location updates will generally not change call signaling in real time, although it may be possible to do so. Here are a few scenario's which may be defensible. 1. Call setup based on initial location / updated location is sent to PSAP / PSAP transfers to more appropriate PSAP. 2. Call setup started per initial location / updated location is made available to UA (or proxy) during call setup / UA (or proxy) reinitializes SIP signaling based on alternate mapping result. I don't know how feasible no. 2 is, since signaling usually happens a lot quicker than location updates, but I think that the requirement (I39), as it is presently worded, covers both cases. Roger Marshall. >-----Original Message----- >From: Tom-PT Taylor [mailto:taylor@nortel.com]=20 >Sent: Tuesday, October 18, 2005 5:14 AM >To: Roger Marshall >Cc: ECRIT >Subject: Re: [Ecrit] Final comments on ecrit-requirements-00 > >Sorry, I still don't see how a location update can affect call=20 >routing, unless you are saying the setup should wait several=20 >seconds in case an update comes along. Unless that is what=20 >you mean, I39 is irrelevant to the routing process -- any=20 >location update will come after setup has been launched. > >Roger Marshall wrote: >... >>=20 >>=20 >>>I39 doesn't make any sense in the general context of call setup. =20 >>>Surely it doesn't imply that a call already set up will suddenly be=20 >>>yanked off to another PSAP based on more accurate data. I'd suggest=20 >>>the relevant aspect is covered by I42, and the rest is a matter of=20 >>>what is presented to the call taker. >>=20 >>=20 >> I think you're right, that we should be clear as to what=20 >implications=20 >> are stated within the motivation. I39 itself is general (a=20 >good thing). >> How's an update can be used, either during call signaling or=20 >> afterward, I'd rather not address with this requirement. >>=20 >> I39. Location Updates: It SHOULD be possible to have updates of=20 >> location. >>=20 >> Proposed new motivation text: >>=20 >> Motivation: Updated location information may have an impact on PSAP=20 >> routing. In some cases it may be possible to redirect that=20 >call to a=20 >> more appropriate PSAP (some device measurement techniques provide=20 >> quick (i.e. early), but imprecise "first fix" location). >>=20 >>=20 >... > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 18 15:04:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERwkl-0008LV-EE; Tue, 18 Oct 2005 15:04:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERwkk-0008KA-G5 for ecrit@megatron.ietf.org; Tue, 18 Oct 2005 15:04:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22436 for ; Tue, 18 Oct 2005 15:03:53 -0400 (EDT) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERwwI-0007SH-2K for ecrit@ietf.org; Tue, 18 Oct 2005 15:15:58 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1ERwkO-0003gQ-R6 for ecrit@ietf.org; Tue, 18 Oct 2005 14:03:41 -0500 From: "Brian Rosen" To: Date: Tue, 18 Oct 2005 14:57:24 -0400 Message-ID: <03e801c5d415$c9641bb0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXUFcaPKbKgTeBGSousxfaSpIJZYg== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.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.5 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Subject: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00 - Indentifying Emergency Calls X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2119637269==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============2119637269== Content-Type: multipart/alternative; boundary="----=_NextPart_000_03E9_01C5D3F4.42527BB0" This is a multi-part message in MIME format. ------=_NextPart_000_03E9_01C5D3F4.42527BB0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit NENA has reviewed draft-ietf-ecrit-requirements-00, and specifically has compared them to the draft-rosen-nena-ecrit-requirements-00. We commend the author of the ecrit draft for merging many conflicting source documents. We have a number of comments. I have broken them up relatively arbitrarily by topic to keep the email threads more relevant, but there is no significance to the topic. Requirement A1 is not sufficient, because it does not include the step of disseminating the local emergency dial code ("9-1-1" "1-1-2", etc) and provide for the mapping of the local code to the universal identifier. Need at least one, and possibly two additional requirements: Requirement A1c is not specific enough. First of all, we need to distinguish a universal identifier from forms of QoS marking. A1c may imply QoS marking, when some other form of marking was intended. This should be clarified. Finally, we DO think QoS marking is a requirement, and we think that applies separately to the session signaling and the packets in which signaling and media are sent. ------=_NextPart_000_03E9_01C5D3F4.42527BB0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

NENA has reviewed draft-ietf-ecrit-requirements-00, and = specifically has compared them to the draft-rosen-nena-ecrit-requirements-00.  = We commend the author of the ecrit draft for merging many conflicting = source documents.  We have a number of comments.  I have broken them = up relatively arbitrarily by topic to keep the email threads more relevant, = but there is no significance to the topic.

 

Requirement A1 is not sufficient, because it does not include = the step of disseminating the local emergency dial code (“9-1-1” “1-1-2”, etc) and provide for the mapping of the local code = to the universal identifier.   Need at least one, and possibly two additional requirements:

 

Requirement A1c is not specific enough.  First of all, we = need to distinguish a universal identifier from forms of QoS marking.  A1c = may imply QoS marking, when some other form of marking was intended.  = This should be clarified.  Finally, we DO think QoS marking is a = requirement, and we think that applies separately to the session signaling and the = packets in which signaling and media are sent.  =

 

------=_NextPart_000_03E9_01C5D3F4.42527BB0-- --===============2119637269== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============2119637269==-- From ecrit-bounces@ietf.org Tue Oct 18 15:04:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERwlQ-0008UM-9q; Tue, 18 Oct 2005 15:04:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERwlO-0008UE-Eq for ecrit@megatron.ietf.org; Tue, 18 Oct 2005 15:04:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22464 for ; Tue, 18 Oct 2005 15:04:33 -0400 (EDT) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERwwy-0007TP-Vg for ecrit@ietf.org; Tue, 18 Oct 2005 15:16:41 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1ERwlE-0003jm-3i for ecrit@ietf.org; Tue, 18 Oct 2005 14:04:32 -0500 From: "Brian Rosen" To: Date: Tue, 18 Oct 2005 14:58:17 -0400 Message-ID: <03f001c5d415$e808f4f0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXUFeX8wpzsAP7sT7O87+dhkPMmoA== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.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: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Subject: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00 - Alternate Routes X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0782645838==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0782645838== Content-Type: multipart/alternative; boundary="----=_NextPart_000_03F1_01C5D3F4.60F754F0" This is a multi-part message in MIME format. ------=_NextPart_000_03F1_01C5D3F4.60F754F0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit More comments from NENA: In our requirement 3.4-4, we said, Mechanisms must be provided to route emergency calls in areas not served by E9-1-1 to an appropriate PSTN telephone number. I31 is related to this, but doesn't cover it adequately we feel. One way to improve it would be to use a tel uri with an e.164 as an example. The issue of "default routing" must be covered in the requirements. This occurs when less than complete information or inconsistent information is provided (for example, good community name, but bad street name). In these cases, some entity must determine a route. In general, there is a "default" route for levels of the address hierarchy when data below that level is missing or inaccurate. Generally, this is a "longest prefix match" problem. The mapping function could do this itself, or it could accept a less than complete query (no data below city name for example), and return a mapping, pushing the error resolution process back to the entity requesting mapping. We would prefer that the mapping function return a valid default mapping if partial data is provided or data is inconsistent. There are similar mechanisms needed for geo routing. As a separate requirement, it is important that somehow, the destination know that default routing was used. This implies that the mapping result includes some kind of flag that default routing was used, and that flag can be propagated downstream. Requirement I31b: The mapping protocol MUST be able to return a URI or contact method explicitly marked as an alternate contact does not adequately address our requirement 3.6-19: Multiple types of failures may have different contingency routes. ------=_NextPart_000_03F1_01C5D3F4.60F754F0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

More comments from NENA:

 

In our requirement 3.4-4, we said, Mechanisms must be provided = to route emergency calls in areas not served by E9-1-1 to an appropriate PSTN = telephone number.  I31 is related to this, but doesn’t cover it = adequately we feel.  One way to improve it would be to use a tel uri with an = e.164 as an example.

 

The issue of “default routing” must be covered in = the requirements.  This occurs when less than complete information or inconsistent information is provided (for example, good community name, = but bad street name).  In these cases, some entity must determine a = route.  In general, there is a “default” route for levels of the = address hierarchy when data below that level is missing or inaccurate.  = Generally, this is a “longest prefix match” problem.  The mapping function could do this itself, or it could accept a less than complete = query (no data below city name for example), and return a mapping, pushing the = error resolution process back to the entity requesting mapping.  We would = prefer that the mapping function return a valid default mapping if partial data = is provided or data is inconsistent.  There are similar mechanisms = needed for geo routing.  As a separate requirement, it is important that = somehow, the destination know that default routing was used.  This implies that = the mapping result includes some kind of flag that default routing was used, and = that flag can be propagated downstream.

 

Requirement I31b: The mapping protocol MUST be able to return a = URI or contact method explicitly marked as an alternate contact does not = adequately address our requirement 3.6-19: Multiple types of failures may have = different contingency routes.

 

------=_NextPart_000_03F1_01C5D3F4.60F754F0-- --===============0782645838== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0782645838==-- From ecrit-bounces@ietf.org Tue Oct 18 15:07:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERwnk-0000cy-P4; Tue, 18 Oct 2005 15:07:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERwnj-0000cq-8l for ecrit@megatron.ietf.org; Tue, 18 Oct 2005 15:07:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22556 for ; Tue, 18 Oct 2005 15:06:57 -0400 (EDT) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERwzJ-0007Wx-LA for ecrit@ietf.org; Tue, 18 Oct 2005 15:19:06 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1ERwnX-0003qr-VV for ecrit@ietf.org; Tue, 18 Oct 2005 14:06:56 -0500 From: "Brian Rosen" To: Date: Tue, 18 Oct 2005 15:00:41 -0400 Message-ID: <03f501c5d416$3dfb8530$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXUFjwr5CgZFcrLQHmsJ7X4ulo6rQ== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.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: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00 Misc X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Final set of comments from NENA: Requirement R7 may need some more text.=A0 First of all, the word = =93modes=94 may be confusing.=A0 Consider =93media types=94.=A0 Then, this requirement = has non obvious consequences, which may need to be included in the = requirements.=A0 For example, when a relay is used, the location of the caller, not the location of the relay must be used for routing.=A0 Just saying it must = be possible to have a relay doesn=92t imply routing on the location of the caller, since it may be the relay that originates the call.=A0 Also note = the subtlety that location may be automatically be supplied when emergency = calls are placed, but not when calls are placed to relays.=A0 If the relay =93elevates=94 the call to be an emergency call, location has to be made available.=A0 This may interact with the ecrit charter item on = identifying calls as emergency calls (the call to the relay is not an emergency call originally), but mostly points out yet again that there is no =93big = picture=94 of how emergency calls work in the IETF.=20 Requirement I7 was narrowed from our original requirement 3.1-1 to only encompass the entities doing the mapping.=A0 We understand that this was necessary to meet the charter limitations of ecrit.=A0 Again, this = points out the issue that there is no place to take the general requirement.=A0 Specifically, however, the real requirement is actually that the PSAP = knows who did the mapping (UA or proxy).=A0 This is not covered; I7 says the = entity requesting mapping knows the source of the mapping data.=20 We note that there is no actual requirement to support both geo or civic based mapping.=A0 It is implied, but not required.=A0 Also note our = requirement 3.6-3, where we wished to have a requirement that the mapping function = not require a conversion (albeit not prohibiting an implementation from = using conversion) to determine the mapping.=A0 Conversion introduces error, = and it may be important to not have that error.=A0 There are also some = requirements we had on control of conversion data (36-4 to 3,6-6) which may be needed depending on how the final requirements come out.=20 We note that while there was a great discussion on the list on what = happens if there is more than one location source, and we agree it is not the mapping functions responsibility to decide which of several locations = should be used, we none-the-less must mention this issue somewhere, and specifically state what happens if there is more than one presented to = the mapping function.=20 In our requirement 3.5-3, we requested If it is determined that an = address is invalid, an error diagnosis should be supplied if appropriate, as = well as a contact URI for resolving errors in the database. This is an = important requirement, and needs to be included in the ecrit mechanism.=20 There is no equivalent of our Requirement 3.6-11: Routing databases = using 9-1-1 Valid Addresses or lat/lon/altitude as keys must both be available = to all entities needing to route 9-1-1 calls.=A0 It is particularly = important that entities be able to map where the entity is not near, and has no relationships with, any entities within the area of the endpoint (unless = it is always the endpoint that does the mapping).=20 There is a currently running discussion on when mapping is done.=A0 = Please note our requirement 3.6-15: Routing as specified in Req ? may change on short notice due to local conditions, traffic, failures, schedule, etc.=20 We do not believe our requirement 3.6-14 has been included: It is = desirable for higher level civic authorities such as a county or state/province to = be able to make common routing decisions for all PSAPs within their jurisdiction.=A0 For example, a state may wish to have all emergency = calls placed within that state directed to a specific URI.=A0 This does NOT = imply a single answering point; further routing may occur beyond the common URI = is adequately covered.=A0 D7 isn=92t it.=A0 This is the notion of an ESRP, = but there do not appear to be any requirements that say this is possible.=A0 One = of the considerations we may wish to consider is how the ESRP routes.=A0 One mechanism would be to allow the information returned to be dependent on = the entity querying.=A0 There may be other mechanisms.=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 18 16:29:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERy5m-0003GM-F8; Tue, 18 Oct 2005 16:29:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERy5j-0003F9-8L for ecrit@megatron.ietf.org; Tue, 18 Oct 2005 16:29:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08444 for ; Tue, 18 Oct 2005 16:29:36 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERyHG-0005TF-HH for ecrit@ietf.org; Tue, 18 Oct 2005 16:41:43 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Tue, 18 Oct 2005 16:29:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00 -Indentifying Emergency Calls Date: Tue, 18 Oct 2005 13:29:30 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A6575035F605A@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00 -Indentifying Emergency Calls Thread-Index: AcXUFcaPKbKgTeBGSousxfaSpIJZYgACF2SQ From: "Roger Marshall" To: , X-Spam-Score: 0.2 (/) X-Scan-Signature: ebd5ffc455fd7bcccba963126e1cf1f5 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1667653264==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1667653264== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D422.A446228A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D422.A446228A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 10/18/05, Brian Rosen wrote: =20 >Requirement A1 is not sufficient, because it does not include the step of disseminating the local emergency dial code ("9-1-1" "1-1-2", etc) and >provide for the mapping of the local code to the universal identifier. Need at least one, and possibly two additional requirements: =20 =20 Please send proposed text in the form of requirement(s) to the list for review. =20 >Requirement A1c is not specific enough. First of all, we need to distinguish a universal identifier from forms of QoS marking. A1c may imply QoS >marking, when some other form of marking was intended. This should be clarified. Finally, we DO think QoS marking is a requirement, and we >think that applies separately to the session signaling and the packets in which signaling and media are sent. =20 For the QoS requirement need, please provide proposed text to the list, along with relevant QoS references (RFC's, etc.) which may exist already as a basis for discussion. Examples of QoS in signaling would be helpful to the discussion. =20 =20 Based on the other suggestions for clarity, I am proposing a change to the existing (as modified) A1c requirement: =20 Original (published) requirement:=20 =20 A1c. Emergency Marking: Emergency requests which are not already marked as emergency calls, MUST be recognizable and marked by user agents, proxies, and other network elements as emergency calls. Existing (as modified per Tom Taylor's comments) requirement: A1c. Emergency Marking:"> Any device in the signaling that recognizes by some means that the signaling is associated an emergency call MUST add the emergency indication called for A1a to the signaling before forwarding it. =20 Proposed changed text per Brian's suggestion: =20 A1c. Emergency Marking: Any device in the signaling that recognizes by some means that the signaling is associated an emergency call MUST add the emergency indication called for A1a to the signaling before forwarding it. This marking mechanism must be different than QoS marking. =20 Motivation: Marking ensures proper handling as an emergency call downstream elements that may not recognize, for example, a variant of a logical emergency address (see requirement A4+). =20 =20 Does this address NENA's concern for the A1c requirement? Comments from others with regard to this QoS exemption? =20 Thanks. =20 Roger Marshall =20 =20 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Tuesday, October 18, 2005 11:57 AM To: ecrit@ietf.org Subject: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00 -Indentifying Emergency Calls =09 =09 NENA has reviewed draft-ietf-ecrit-requirements-00, and specifically has compared them to the draft-rosen-nena-ecrit-requirements-00. We commend the author of the ecrit draft for merging many conflicting source documents. We have a number of comments. I have broken them up relatively arbitrarily by topic to keep the email threads more relevant, but there is no significance to the topic. =20 Requirement A1 is not sufficient, because it does not include the step of disseminating the local emergency dial code ("9-1-1" "1-1-2", etc) and provide for the mapping of the local code to the universal identifier. Need at least one, and possibly two additional requirements: =20 =20 Requirement A1c is not specific enough. First of all, we need to distinguish a universal identifier from forms of QoS marking. A1c may imply QoS marking, when some other form of marking was intended. This should be clarified. Finally, we DO think QoS marking is a requirement, and we think that applies separately to the session signaling and the packets in which signaling and media are sent. =20 =20 ------_=_NextPart_001_01C5D422.A446228A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
On=20 10/18/05, Brian Rosen wrote:
 
>Requirement A1 is not sufficient, because it does = not include=20 the step of disseminating the local emergency dial code = (“9-1-1” “1-1-2”, etc)=20 and >provide for the mapping of the local code to the universal = identifier.=20   Need at least one, and possibly two additional=20 requirements:  
&nbs= p;
Please send proposed = text in the=20 form of requirement(s) to the list for=20 review.
&nbs= p;
>Requirement A1c is not specific = enough.  First=20 of all, we need to distinguish a universal identifier from forms of QoS = marking.=20  A1c may imply QoS >marking, when some other form of marking was = intended.  This should be clarified.  Finally, we DO think QoS = marking=20 is a requirement, and we >think that applies separately to the = session=20 signaling and the packets in which signaling and media are=20 sent.
 
For=20 the QoS requirement need, please provide proposed text to the = list,=20 along with relevant QoS references (RFC's, etc.) which may = exist=20 already as a basis for discussion.  Examples of QoS in signaling = would be=20 helpful to the=20 discussion.
 
 
Based=20 on the other suggestions for clarity, I am proposing a change to = the=20 existing (as modified) A1c=20 requirement:
 
Original (published) requirement:=20
 
A1c.  Emergency Marking: Emergency = requests which=20 are not already
  marked as emergency calls, MUST be = recognizable=20 and marked by user
  agents, proxies, and other network = elements as=20 emergency = calls.

Existing = (as modified=20 per Tom Taylor's comments)=20 requirement:
<= /FONT>
A1c. Emergency=20 Marking:"> = Any device=20 in the signaling that recognizes by some means that the signaling is = associated=20 an emergency call MUST add the emergency indication called for A1a to = the=20 signaling before forwarding=20 it.
&= nbsp;
Proposed changed text = per Brian's=20 suggestion:
=
 
A1c.  Emergency Marking: Any device in = the=20 signaling that recognizes by some means that the signaling is associated = an=20 emergency call MUST add the emergency indication called for A1a to the = signaling=20 before forwarding it.  This marking mechanism must be = different=20 than QoS = marking.
 
Motivation: Marking ensures proper handling as = an=20 emergency call downstream elements that may not recognize, for example, = a=20 variant of a logical emergency address (see requirement=20 A4+).
 
 
Does this address NENA's concern for the = A1c=20 requirement?  Comments from others with regard to this QoS=20 exemption?
 
Thanks.
 
Roger=20 Marshall
 
 <= /DIV>
From: ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian=20 Rosen
Sent: Tuesday, October 18, 2005 11:57 AM
To: = ecrit@ietf.org
Subject: [Ecrit] NENA Comments on=20 draft-ietf-ecrit-requirements-00 -Indentifying Emergency=20 Calls

NENA has reviewed = draft-ietf-ecrit-requirements-00,=20 and specifically has compared them to the=20 draft-rosen-nena-ecrit-requirements-00.  We commend the author of = the=20 ecrit draft for merging many conflicting source documents.  We = have a=20 number of comments.  I have broken them up relatively arbitrarily = by=20 topic to keep the email threads more relevant, but there is no = significance to=20 the topic.

 

Requirement A1 is not sufficient, because it = does not=20 include the step of disseminating the local emergency dial code = (“9-1-1”=20 “1-1-2”, etc) and provide for the mapping of the local = code to the universal=20 identifier.   Need at least one, and possibly two additional = requirements:   <= /FONT>

 

Requirement A1c is not specific = enough.  First of=20 all, we need to distinguish a universal identifier from forms of QoS = marking.=20  A1c may imply QoS marking, when some other form of marking was=20 intended.  This should be clarified.  Finally, we DO think = QoS=20 marking is a requirement, and we think that applies separately to the = session=20 signaling and the packets in which signaling and media are sent.  =

 

------_=_NextPart_001_01C5D422.A446228A-- --===============1667653264== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1667653264==-- From ecrit-bounces@ietf.org Tue Oct 18 16:49:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERyP8-0007jh-9c; Tue, 18 Oct 2005 16:49:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERyP7-0007jQ-0h for ecrit@megatron.ietf.org; Tue, 18 Oct 2005 16:49:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16864 for ; Tue, 18 Oct 2005 16:49:40 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERyag-0000CG-Sm for ecrit@ietf.org; Tue, 18 Oct 2005 17:01:47 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Tue, 18 Oct 2005 16:49:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes Date: Tue, 18 Oct 2005 13:49:35 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A6575035F60B2@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes Thread-Index: AcXUFeX8wpzsAP7sT7O87+dhkPMmoAADXQAg From: "Roger Marshall" To: , X-Spam-Score: 0.9 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1239551800==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1239551800== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D425.73EE3C2A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D425.73EE3C2A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Brian: Please send proposed requirements text which addresses NENA's concerns. It may also be helpful to provide examples of the different levels of "default routing" and how this might be represented within the messaging (after the mapping result is returned to the mapping client). =20 Roger Marshall. ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Tuesday, October 18, 2005 11:58 AM To: ecrit@ietf.org Subject: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes =09 =09 More comments from NENA: =20 In our requirement 3.4-4, we said, Mechanisms must be provided to route emergency calls in areas not served by E9-1-1 to an appropriate PSTN telephone number. I31 is related to this, but doesn't cover it adequately we feel. One way to improve it would be to use a tel uri with an e.164 as an example.=20 =20 The issue of "default routing" must be covered in the requirements. This occurs when less than complete information or inconsistent information is provided (for example, good community name, but bad street name). In these cases, some entity must determine a route. In general, there is a "default" route for levels of the address hierarchy when data below that level is missing or inaccurate. Generally, this is a "longest prefix match" problem. The mapping function could do this itself, or it could accept a less than complete query (no data below city name for example), and return a mapping, pushing the error resolution process back to the entity requesting mapping. We would prefer that the mapping function return a valid default mapping if partial data is provided or data is inconsistent. There are similar mechanisms needed for geo routing. As a separate requirement, it is important that somehow, the destination know that default routing was used. This implies that the mapping result includes some kind of flag that default routing was used, and that flag can be propagated downstream. =20 Requirement I31b: The mapping protocol MUST be able to return a URI or contact method explicitly marked as an alternate contact does not adequately address our requirement 3.6-19: Multiple types of failures may have different contingency routes. =20 ------_=_NextPart_001_01C5D425.73EE3C2A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Brian:
Please send proposed requirements text = which=20 addresses NENA's concerns.  It may also be helpful to provide = examples=20 of the different levels of "default routing" and how this might be = represented=20 within the messaging (after the mapping result is returned to the = mapping=20 client).
 
Roger Marshall.

From: ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian=20 Rosen
Sent: Tuesday, October 18, 2005 11:58 AM
To: = ecrit@ietf.org
Subject: [Ecrit] NENA Comments on=20 draft-ietf-ecrit-requirements-00 -Alternate = Routes

More comments from = NENA:

 

In our requirement 3.4-4, we said, = Mechanisms must be=20 provided to route emergency calls in areas not served by E9-1-1 to an=20 appropriate PSTN telephone number.  I31 is related to this, but = doesn’t=20 cover it adequately we feel.  One way to improve it would be to = use a tel=20 uri with an e.164 as an example.

 

The issue of “default routing” = must be covered in the=20 requirements.  This occurs when less than complete information or = inconsistent information is provided (for example, good community = name, but=20 bad street name).  In these cases, some entity must determine a=20 route.  In general, there is a “default” route for = levels of the address=20 hierarchy when data below that level is missing or inaccurate. =20 Generally, this is a “longest prefix match” problem.  = The mapping=20 function could do this itself, or it could accept a less than complete = query=20 (no data below city name for example), and return a mapping, pushing = the error=20 resolution process back to the entity requesting mapping.  We = would=20 prefer that the mapping function return a valid default mapping if = partial=20 data is provided or data is inconsistent.  There are similar = mechanisms=20 needed for geo routing.  As a separate requirement, it is = important that=20 somehow, the destination know that default routing was used. =  This=20 implies that the mapping result includes some kind of flag that = default=20 routing was used, and that flag can be propagated=20 downstream.

 

Requirement I31b: The mapping protocol MUST = be able to=20 return a URI or contact method explicitly marked as an alternate = contact does=20 not adequately address our requirement 3.6-19: Multiple types of = failures may=20 have different contingency routes.

 

------_=_NextPart_001_01C5D425.73EE3C2A-- --===============1239551800== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1239551800==-- From ecrit-bounces@ietf.org Tue Oct 18 17:54:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERzPw-0008Qe-Id; Tue, 18 Oct 2005 17:54:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERzPq-0008QO-Fr for ecrit@megatron.ietf.org; Tue, 18 Oct 2005 17:54:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02480 for ; Tue, 18 Oct 2005 17:54:29 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERzbR-0005pa-7E for ecrit@ietf.org; Tue, 18 Oct 2005 18:06:38 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Tue, 18 Oct 2005 17:54:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Comment on ecrit-requirements-00 Date: Tue, 18 Oct 2005 14:54:20 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A6575035F61C2@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Comment on ecrit-requirements-00 Thread-Index: AcXE1qYFtg3q6Dn5S860bQ0EpdIFGAAKOAtAA8tj/hA= From: "Roger Marshall" To: "Abbott, Nadine B" , "ECRIT" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org All: There have been no comments to Nadine's proposal to add an ECRIT requirement which talks about the test environment. I've provided what I think Nadine is getting at, below: XX - There MUST be a mechanism to support the ability to differentiate an actual emergency call from a "test" call. Motivation: Since test calls will be required alongside normal VoIP E9-1-1 calls, there needs to be a way preventing such test calls from getting in the way of valid emergency calls under certain circumstances. =20 Any objections to adding the above requirement to the draft? Thanks. Roger Marshall.=20 >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Abbott, Nadine B >Sent: Thursday, September 29, 2005 7:27 AM >To: ECRIT >Subject: [Ecrit] Comment on ecrit-requirements-00=20 > >Suggest that we add in to Section 6 a requirement for the=20 >capability to distinguish an emergency "test call" as=20 >previously described in I-Ds on emergency services=20 >architectures. This is necessary so that the emergency service=20 >that receives the call can provide different processing for=20 >such test calls. Proposed text: > > >It must be possible to distinguish an emergency "test call." > > Ax?. Emergency Test Call Marking: Emergency test requests=20 >MUST be recognizable and marked =20 > by user agents, proxies, and other network elements as=20 >emergency test calls. > > Motivation: SIP and other call signaling protocols are not > specific to one country or service provider and devices=20 >are likely > to be used across national or service provider boundaries. Since > services such as disabling mandatory authentication for emergency > calls requires the cooperation of outbound proxies, the outbound > proxy has to be able to recognize the emergency test call and be > assured that it will be routed as an emergency call.=20 >However, the PSAP=20 > receiving the call will want to handle the emergency=20 >test call differently > from a real emergency call. > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 18 18:04:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERzZF-0004Zh-Oa; Tue, 18 Oct 2005 18:04:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERzZD-0004Yy-FN for ecrit@megatron.ietf.org; Tue, 18 Oct 2005 18:04:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03021 for ; Tue, 18 Oct 2005 18:04:11 -0400 (EDT) Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERzko-00064s-Q9 for ecrit@ietf.org; Tue, 18 Oct 2005 18:16:19 -0400 Received: from [10.0.1.103] ([::ffff:64.83.8.179]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Tue, 18 Oct 2005 18:04:01 -0400 id 01588073.43557151.00007BE9 In-Reply-To: <8C837214C95C864C9F34F3635C2A65750358A432@SEA-EXCHVS-2.telecomsys.com> References: <8C837214C95C864C9F34F3635C2A65750358A432@SEA-EXCHVS-2.telecomsys.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Final comments on ecrit-requirements-00 Date: Tue, 18 Oct 2005 18:04:04 -0400 To: Roger Marshall X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Oct 17, 2005, at 7:59 PM, Roger Marshall wrote: > Therefore, I propose to remove this performance section in the next > draft. Is there agreement to this move? I agree with this. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 18 19:42:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES16B-0006OB-Hd; Tue, 18 Oct 2005 19:42:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES169-0006O6-II for ecrit@megatron.ietf.org; Tue, 18 Oct 2005 19:42:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07315 for ; Tue, 18 Oct 2005 19:42:16 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES1Hk-0008H7-B3 for ecrit@ietf.org; Tue, 18 Oct 2005 19:54:26 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id for ; Tue, 18 Oct 2005 19:42:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [ECRIT]: Caller Identity requirements: replacement text for empty section in ECRIT req doc. Date: Tue, 18 Oct 2005 16:42:10 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A6575035F6367@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [ECRIT]: Caller Identity requirements: replacement text for empty section in ECRIT req doc. Thread-Index: AcXT3Y4AM/FQSqnNRaiWsmbORCxXIgAWwzzA From: "Roger Marshall" To: "ECRIT" X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org All: There has been a placeholder within the ECRIT requirements draft titled, "Emergency Caller Identification". Since this section was requested back on 8/09, I guess I'll take a crack at submitting some (proposed) text for it (below): "When a person places an emergency call to a PSAP, existing emergency service messaging conveys associated caller information in addition to receiving the caller's voice. This additional information typically consists of a call-back number, and the caller's location (referred to as ANI and ALI, for North American systems)." "Some systems use the received callback number to perform a identity lookup via a database lookup service, and then use the location information received to help verify the caller's identity presented both via voice, as well as the external data presented from the identity database query. These external mechanisms are important for many reasons, including helping callers who cannot, or will not speak, to prevent false information from impeding appropriate dispatch instructions and procedures, and ultimately to enable faster response in the offering of help." "IP-based emergency systems in the future may be able to offer even more information about the caller, to help establish personal identity, but also for today, for near-term implementations, need to provide the same minimum level of identitifcation support as in the existing legacy emergency systems." "Req1: A "Call-back" number MUST be supplied within the call signaling for each emergency call sent to the PSAP. The ECRIT protocol may provide this number in the form of a tel:uri, a sip:uri, or an IP-Address." "Req2: The ECRIT protocol MUST support the ability for the PSAP to perform caller identity lookup based on the tel:uri, sip:uri, or IP Address provided with call signaling. (A variety of competing directory lookup services may exist, but is not discussed in detail here, as it is out of scope of this document.)" "Req3: The ECRIT protocol MUST support the ability to associate individual call location information with external caller identity records." I have attempted to steer clear of obvious privacy concerns/objections, modeling this after what's available today in ES, but there are more details that some may want to tease out. Comments? Roger Marshall. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 18 19:43:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES17M-0006kp-W3; Tue, 18 Oct 2005 19:43:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES17L-0006kX-Es for ecrit@megatron.ietf.org; Tue, 18 Oct 2005 19:43:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07366 for ; Tue, 18 Oct 2005 19:43:30 -0400 (EDT) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES1Iv-0008It-Uw for ecrit@ietf.org; Tue, 18 Oct 2005 19:55:40 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Oct 2005 18:43:19 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Tue, 18 Oct 2005 18:43:18 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Oct 2005 18:43:18 -0500 Message-ID: From: "Winterbottom, James" To: "Roger Marshall" , , Date: Tue, 18 Oct 2005 18:43:16 -0500 Subject: RE: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00-Indentifying Emergency Calls MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 18 Oct 2005 23:43:18.0110 (UTC) FILETIME=[B72B77E0:01C5D43D] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00-Indentifying Emergency Calls Thread-Index: AcXUFcaPKbKgTeBGSousxfaSpIJZYgACF2SQAAfc5mA= X-Spam-Score: 0.4 (/) X-Scan-Signature: 231d7929942febf3be8fd5be2903302f Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0447813282==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0447813282== Content-Type: multipart/alternative; boundary="--=_NextPart_ST_18_43_18_Tuesday_October_18_2005_2095" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ----=_NextPart_ST_18_43_18_Tuesday_October_18_2005_2095 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is it pertinent to know which node in the signaling path decided to promote the urgency of the call?=20 =20 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: Wednesday, 19 October 2005 6:30 AM To: br@brianrosen.net; ecrit@ietf.org Subject: RE: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00-Indentifying Emergency Calls =20 On 10/18/05, Brian Rosen wrote: =20 >Requirement A1 is not sufficient, because it does not include the step of disseminating the local emergency dial code ("9-1-1" "1-1-2", etc) and >provide for the mapping of the local code to the universal identifier. Need at least one, and possibly two additional requirements: =20 =20 Please send proposed text in the form of requirement(s) to the list for review. =20 >Requirement A1c is not specific enough. First of all, we need to distinguish a universal identifier from forms of QoS marking. A1c may imply QoS >marking, when some other form of marking was intended. This should be clarified. Finally, we DO think QoS marking is a requirement, and we >think that applies separately to the session signaling and the packets in which signaling and media are sent. =20 For the QoS requirement need, please provide proposed text to the list, along with relevant QoS references (RFC's, etc.) which may exist already as a basis for discussion. Examples of QoS in signaling would be helpful to the discussion. =20 =20 Based on the other suggestions for clarity, I am proposing a change to the existing (as modified) A1c requirement: =20 Original (published) requirement:=20 =20 A1c. Emergency Marking: Emergency requests which are not already marked as emergency calls, MUST be recognizable and marked by user agents, proxies, and other network elements as emergency calls. Existing (as modified per Tom Taylor's comments) requirement: A1c. Emergency Marking:"> Any device in the signaling that recognizes by some means that the signaling is associated an emergency call MUST add the emergency indication called for A1a to the signaling before forwarding it. =20 Proposed changed text per Brian's suggestion: =20 A1c. Emergency Marking: Any device in the signaling that recognizes by some means that the signaling is associated an emergency call MUST add the emergency indication called for A1a to the signaling before forwarding it. This marking mechanism must be different than QoS marking. =20 Motivation: Marking ensures proper handling as an emergency call downstream elements that may not recognize, for example, a variant of a logical emergency address (see requirement A4+). =20 =20 Does this address NENA's concern for the A1c requirement? Comments from others with regard to this QoS exemption? =20 Thanks. =20 Roger Marshall =20 =20 ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] ----=_NextPart_ST_18_43_18_Tuesday_October_18_2005_2095 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Is it pertinent to know which node in = the signaling path decided to promote the urgency of the call? <= /p>

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall
Sent: Wednesday, 19 October = 2005 6:30 AM
To: br@brianrosen.net; ecrit@ietf.org
Subject: RE: [Ecrit] NENA Co= mments on draft-ietf-ecrit-requirements-00-Indentifying Emergency Calls

 

On 10/18/05, Brian Rosen wrote:

 

>Requirement A1 is not sufficient, because it does not include the step of disseminating the local emergency d= ial code (“9-1-1” “1-1-2”, etc) and >provide for the mapping of the local code to the universal identifier.   Need at least one, and possibly two additional requirements:  

 

Please send proposed text in the form= of requirement(s) to the list for review.

 

>Requirement A1c is not specific e= nough.  First of all, we need to distinguish a universal identifier from forms of Q= oS marking.  A1c may imply QoS >marking, when some other form of marki= ng was intended.  This should be clarified.  Finally, we DO think Qo= S marking is a requirement, and we >think that applies separately to the session signaling and the packets in which signaling and media are sent.

 

For the QoS requirement need, please provide proposed text to the list, along with relevant QoS references (RFC's, etc.) which may exist already as a basis for discussion.  Examples of QoS in signaling would be helpful to the discussion.

 

 

Based on the other suggestions f= or clarity, I am proposing a change to the existing (as modified) A1c requirement:

 

Original (published) requirement:

 

A1c.  Emergency Marking: Emergen= cy requests which are not already
  marked as emergency calls, MUST be recognizable and marked by u= ser
  agents, proxies, and other network elements as emergency calls.=

Existing (as modified per Tom Taylor's comments) requirement:=

A1c. Emergency Marking:= "> Any device in the signaling that recognizes by some means that the signaling is associated an emergency call MUST add the emergency indication called for A1a to the signaling before forwarding it.

 

Proposed changed text per Brian's suggestion:

 

A1c.  Emergency Marking: Any dev= ice in the signaling that recognizes by some means that the signaling is associ= ated an emergency call MUST add the emergency indication called for A1a to the signaling before forwarding it.  This marking mechanism must be different than QoS marking.

 

Motivation: Marking ensures proper handling as an emergency call downstream elements that may not recognize, f= or example, a variant of a logical emergency address (see requirement A4+).

 

 

Does this address NENA's concern= for the A1c requirement?  Comments from others with regard to this QoS exemption?

 

Thanks.

 

Roger Marshall

 

 


-----------------------------------------------------------------------= -------------------------
This message is for the designated recipient o= nly and may
contain privileged, proprietary, or otherwise private inform= ation.
If you have received it in error, please notify the sender
i= mmediately and delete the original. Any unauthorized use of
this email = is prohibited.
---------------------------------------------------------= ---------------------------------------
[mf2] ----=_NextPart_ST_18_43_18_Tuesday_October_18_2005_2095-- --===============0447813282== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0447813282==-- From ecrit-bounces@ietf.org Tue Oct 18 21:40:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES2wS-00038g-FW; Tue, 18 Oct 2005 21:40:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES2wR-00038a-Ec for ecrit@megatron.ietf.org; Tue, 18 Oct 2005 21:40:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11980 for ; Tue, 18 Oct 2005 21:40:21 -0400 (EDT) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES380-0002Hr-VQ for ecrit@ietf.org; Tue, 18 Oct 2005 21:52:31 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Oct 2005 20:40:12 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Tue, 18 Oct 2005 20:40:12 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Oct 2005 20:40:11 -0500 Message-ID: From: "Winterbottom, James" To: "Roger Marshall" , "ECRIT" Date: Tue, 18 Oct 2005 20:40:10 -0500 Subject: RE: [ECRIT]: Caller Identity requirements: replacement text for emptysection in ECRIT req doc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 19 Oct 2005 01:40:11.0918 (UTC) FILETIME=[0BB9A2E0:01C5D44E] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [ECRIT]: Caller Identity requirements: replacement text for emptysection in ECRIT req doc. Thread-Index: AcXT3Y4AM/FQSqnNRaiWsmbORCxXIgAWwzzAAAUJ5OA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Roger, With req 2, I am not sure how you declare that something must be supported, but at the same time say that it is out of scope. I am also not sure that I understand how this is a routing requirement. Will req 1 suffice with what you are trying to achieve? Req 3, is it the responsibility of the ECRIT protocol to provide the capability to make the association, or is it the responsibility of the ECRIT protocol to support the transport of parameters such that some other node may be able to make this association. To my mind there is a difference. Cheers James > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Roger Marshall > Sent: Wednesday, 19 October 2005 9:42 AM > To: ECRIT > Subject: [ECRIT]: Caller Identity requirements: replacement text for > emptysection in ECRIT req doc. >=20 > All: > There has been a placeholder within the ECRIT requirements draft titled, > "Emergency Caller Identification". Since this section was requested > back on 8/09, I guess I'll take a crack at submitting some (proposed) > text for it (below): >=20 >=20 > "When a person places an emergency call to a PSAP, existing emergency > service messaging conveys associated caller information in addition to > receiving the caller's voice. This additional information typically > consists of a call-back number, and the caller's location (referred to > as ANI and ALI, for North American systems)." >=20 > "Some systems use the received callback number to perform a identity > lookup via a database lookup service, and then use the location > information received to help verify the caller's identity presented both > via voice, as well as the external data presented from the identity > database query. These external mechanisms are important for many > reasons, including helping callers who cannot, or will not speak, to > prevent false information from impeding appropriate dispatch > instructions and procedures, and ultimately to enable faster response in > the offering of help." >=20 > "IP-based emergency systems in the future may be able to offer even more > information about the caller, to help establish personal identity, but > also for today, for near-term implementations, need to provide the same > minimum level of identitifcation support as in the existing legacy > emergency systems." >=20 > "Req1: A "Call-back" number MUST be supplied within the call signaling > for each emergency call sent to the PSAP. The ECRIT protocol may > provide this number in the form of a tel:uri, a sip:uri, or an > IP-Address." >=20 > "Req2: The ECRIT protocol MUST support the ability for the PSAP to > perform caller identity lookup based on the tel:uri, sip:uri, or IP > Address provided with call signaling. (A variety of competing directory > lookup services may exist, but is not discussed in detail here, as it is > out of scope of this document.)" >=20 > "Req3: The ECRIT protocol MUST support the ability to associate > individual call location information with external caller identity > records." >=20 >=20 >=20 > I have attempted to steer clear of obvious privacy concerns/objections, > modeling this after what's available today in ES, but there are more > details that some may want to tease out. >=20 > Comments? >=20 > Roger Marshall. >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 19 03:57:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES8oy-0004Be-5k; Wed, 19 Oct 2005 03:57:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES8ow-0004BZ-QO for ecrit@megatron.ietf.org; Wed, 19 Oct 2005 03:57:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28179 for ; Wed, 19 Oct 2005 03:57:01 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES90a-0002f5-Ps for ecrit@ietf.org; Wed, 19 Oct 2005 04:09:15 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j9J7upgJ008944 for ; Wed, 19 Oct 2005 09:56:52 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j9J7up0k021725 for ; Wed, 19 Oct 2005 09:56:51 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 19 Oct 2005 09:56:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5D482.A8B083BD" Date: Wed, 19 Oct 2005 09:53:25 +0200 Message-ID: X-MS-Has-Attach: yes Thread-Topic: I-D ACTION:draft-schulzrinne-ecrit-mapping-arch-00.txt Thread-Index: AcXUJSg3K4f7Oat3SKuGVKiN/k9h3gAVrk6Q From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 19 Oct 2005 07:56:49.0398 (UTC) FILETIME=[A8DF7160:01C5D482] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Subject: [Ecrit] WG: I-D ACTION:draft-schulzrinne-ecrit-mapping-arch-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D482.A8B083BD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable fyi, -----Urspr=FCngliche Nachricht----- Von: i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] Im Auftrag von = Internet-Drafts@ietf.org Gesendet: Dienstag, 18. Oktober 2005 21:50 An: i-d-announce@ietf.org Betreff: I-D ACTION:draft-schulzrinne-ecrit-mapping-arch-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Location-to-URL Mapping Architecture and Framework Author(s) : H. Schulzrinne Filename : draft-schulzrinne-ecrit-mapping-arch-00.txt Pages : 16 Date : 2005-10-18 =09 This document describes an architecture for a global, scalable, resilient and administratively distributed system for mapping geographic location information to URLs. The architecture generalizes well-known approaches found in hierarchical lookup systems such as DNS. The architecture does not depend on using a specific protocol, but does require that protocols can summarize the coverage region of a node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-mapping-arch-= 00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-schulzrinne-ecrit-mapping-arch-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-schulzrinne-ecrit-mapping-arch-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C5D482.A8B083BD Content-Type: application/octet-stream; name="draft-schulzrinne-ecrit-mapping-arch-00.URL" Content-Description: draft-schulzrinne-ecrit-mapping-arch-00.URL Content-Disposition: attachment; filename="draft-schulzrinne-ecrit-mapping-arch-00.URL" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1zY2h1bHpyaW5uZS1lY3JpdC1tYXBwaW5nLWFyY2gtMDAudHh0DQo= ------_=_NextPart_001_01C5D482.A8B083BD Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ------_=_NextPart_001_01C5D482.A8B083BD-- From ecrit-bounces@ietf.org Wed Oct 19 11:43:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESG66-0001U4-Kb; Wed, 19 Oct 2005 11:43:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESG63-0001Tj-0n for ecrit@megatron.ietf.org; Wed, 19 Oct 2005 11:43:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23853 for ; Wed, 19 Oct 2005 11:43:10 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESGHn-0007B9-Fv for ecrit@ietf.org; Wed, 19 Oct 2005 11:55:28 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 19 Oct 2005 11:43:09 -0400 X-IronPort-AV: i="3.97,231,1125892800"; d="scan'208"; a="74021158:sNHT25937604" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9JFgs2D006599; Wed, 19 Oct 2005 11:43:04 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Oct 2005 11:42:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ECRIT]: Caller Identity requirements: replacement text for emptysection in ECRIT req doc. Date: Wed, 19 Oct 2005 11:42:50 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3AE6131@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [ECRIT]: Caller Identity requirements: replacement text for emptysection in ECRIT req doc. Thread-Index: AcXT3Y4AM/FQSqnNRaiWsmbORCxXIgAWwzzAACKbYwA= From: "Michael Hammer \(mhammer\)" To: "Roger Marshall" , "ECRIT" X-OriginalArrivalTime: 19 Oct 2005 15:42:51.0461 (UTC) FILETIME=[C38FA750:01C5D4C3] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Roger, In Req-1, you mention an IP address as a call-back number. Is there some assumed higher level protocol that will be used with that IP address? What will the PSAP operator do with it? Mike > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Roger Marshall > Sent: Tuesday, October 18, 2005 7:42 PM > To: ECRIT > Subject: [ECRIT]: Caller Identity requirements: replacement=20 > text for emptysection in ECRIT req doc.=20 >=20 > All: > There has been a placeholder within the ECRIT requirements=20 > draft titled, "Emergency Caller Identification". Since this=20 > section was requested back on 8/09, I guess I'll take a crack=20 > at submitting some (proposed) text for it (below): >=20 >=20 > "When a person places an emergency call to a PSAP, existing=20 > emergency service messaging conveys associated caller=20 > information in addition to receiving the caller's voice. =20 > This additional information typically consists of a call-back=20 > number, and the caller's location (referred to as ANI and=20 > ALI, for North American systems)." >=20 > "Some systems use the received callback number to perform a=20 > identity lookup via a database lookup service, and then use=20 > the location information received to help verify the caller's=20 > identity presented both via voice, as well as the external=20 > data presented from the identity database query. These=20 > external mechanisms are important for many reasons, including=20 > helping callers who cannot, or will not speak, to prevent=20 > false information from impeding appropriate dispatch=20 > instructions and procedures, and ultimately to enable faster=20 > response in the offering of help." >=20 > "IP-based emergency systems in the future may be able to=20 > offer even more information about the caller, to help=20 > establish personal identity, but also for today, for=20 > near-term implementations, need to provide the same minimum=20 > level of identitifcation support as in the existing legacy=20 > emergency systems." >=20 > "Req1: A "Call-back" number MUST be supplied within the call=20 > signaling for each emergency call sent to the PSAP. The=20 > ECRIT protocol may provide this number in the form of a=20 > tel:uri, a sip:uri, or an IP-Address." >=20 > "Req2: The ECRIT protocol MUST support the ability for the=20 > PSAP to perform caller identity lookup based on the tel:uri,=20 > sip:uri, or IP Address provided with call signaling. (A=20 > variety of competing directory lookup services may exist, but=20 > is not discussed in detail here, as it is out of scope of=20 > this document.)" >=20 > "Req3: The ECRIT protocol MUST support the ability to=20 > associate individual call location information with external=20 > caller identity records." >=20 >=20 >=20 > I have attempted to steer clear of obvious privacy=20 > concerns/objections, modeling this after what's available=20 > today in ES, but there are more details that some may want to=20 > tease out. >=20 > Comments? >=20 > Roger Marshall. >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 19 13:09:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESHRN-0005P9-De; Wed, 19 Oct 2005 13:09:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESHRL-0005M6-WB for ecrit@megatron.ietf.org; Wed, 19 Oct 2005 13:09:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29129 for ; Wed, 19 Oct 2005 13:09:14 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESHd7-0001Qz-Su for ecrit@ietf.org; Wed, 19 Oct 2005 13:21:34 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Wed, 19 Oct 2005 13:09:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ECRIT]: Caller Identity requirements: replacement text for emptysection in ECRIT req doc. Date: Wed, 19 Oct 2005 10:09:04 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A6575035F6726@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [ECRIT]: Caller Identity requirements: replacement text for emptysection in ECRIT req doc. Thread-Index: AcXT3Y4AM/FQSqnNRaiWsmbORCxXIgAWwzzAACKbYwAAAvo3YA== From: "Roger Marshall" To: "Michael Hammer \(mhammer\)" , "ECRIT" X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Michael: It seems that the PSAP needs to know which type of service (application) that the caller could be used to contact the call initiator. For example, if the ECRIT protocol provided an IP Address as the "call-back" number, the protocol SHOULD (or MUST?) provide an indicator as to which application is to be used to target this IP Address (e.g. IM, email, VoIP, etc.). Does this get close to addressing the question you're asking? Roger Marshall. >-----Original Message----- >From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 >Sent: Wednesday, October 19, 2005 8:43 AM >To: Roger Marshall; ECRIT >Subject: RE: [ECRIT]: Caller Identity requirements:=20 >replacement text for emptysection in ECRIT req doc.=20 > >Roger, > >In Req-1, you mention an IP address as a call-back number. Is=20 >there some assumed higher level protocol that will be used=20 >with that IP address? What will the PSAP operator do with it? > >Mike > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf=20 >> Of Roger Marshall >> Sent: Tuesday, October 18, 2005 7:42 PM >> To: ECRIT >> Subject: [ECRIT]: Caller Identity requirements: replacement text for=20 >> emptysection in ECRIT req doc. >>=20 >> All: >> There has been a placeholder within the ECRIT requirements draft=20 >> titled, "Emergency Caller Identification". Since this section was=20 >> requested back on 8/09, I guess I'll take a crack at submitting some=20 >> (proposed) text for it (below): >>=20 >>=20 >> "When a person places an emergency call to a PSAP, existing=20 >emergency=20 >> service messaging conveys associated caller information in=20 >addition to=20 >> receiving the caller's voice. >> This additional information typically consists of a=20 >call-back number,=20 >> and the caller's location (referred to as ANI and ALI, for North=20 >> American systems)." >>=20 >> "Some systems use the received callback number to perform a identity=20 >> lookup via a database lookup service, and then use the location=20 >> information received to help verify the caller's identity presented=20 >> both via voice, as well as the external data presented from the=20 >> identity database query. These external mechanisms are=20 >important for=20 >> many reasons, including helping callers who cannot, or will=20 >not speak,=20 >> to prevent false information from impeding appropriate dispatch=20 >> instructions and procedures, and ultimately to enable faster=20 >response=20 >> in the offering of help." >>=20 >> "IP-based emergency systems in the future may be able to offer even=20 >> more information about the caller, to help establish personal=20 >> identity, but also for today, for near-term implementations, need to=20 >> provide the same minimum level of identitifcation support as in the=20 >> existing legacy emergency systems." >>=20 >> "Req1: A "Call-back" number MUST be supplied within the call=20 >signaling=20 >> for each emergency call sent to the PSAP. The ECRIT protocol may=20 >> provide this number in the form of a tel:uri, a sip:uri, or an=20 >> IP-Address." >>=20 >> "Req2: The ECRIT protocol MUST support the ability for the PSAP to=20 >> perform caller identity lookup based on the tel:uri, sip:uri, or IP=20 >> Address provided with call signaling. (A variety of competing=20 >> directory lookup services may exist, but is not discussed in detail=20 >> here, as it is out of scope of this document.)" >>=20 >> "Req3: The ECRIT protocol MUST support the ability to associate=20 >> individual call location information with external caller identity=20 >> records." >>=20 >>=20 >>=20 >> I have attempted to steer clear of obvious privacy=20 >> concerns/objections, modeling this after what's available=20 >today in ES,=20 >> but there are more details that some may want to tease out. >>=20 >> Comments? >>=20 >> Roger Marshall. >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >>=20 > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 19 13:11:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESHTG-0006YP-6G; Wed, 19 Oct 2005 13:11:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESHTA-0006WG-Be for ecrit@megatron.ietf.org; Wed, 19 Oct 2005 13:11:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29237 for ; Wed, 19 Oct 2005 13:11:07 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESHew-0001V3-CC for ecrit@ietf.org; Wed, 19 Oct 2005 13:23:26 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Wed, 19 Oct 2005 13:11:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ECRIT]: Caller Identity requirements: replacement text for emptysection in ECRIT req doc. Date: Wed, 19 Oct 2005 10:11:05 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A6575035F6733@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [ECRIT]: Caller Identity requirements: replacement text for emptysection in ECRIT req doc. Thread-Index: AcXT3Y4AM/FQSqnNRaiWsmbORCxXIgAWwzzAAAUJ5OAAH847sA== From: "Roger Marshall" To: "Winterbottom, James" , "ECRIT" X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org James: See responses in-line.=20 >-----Original Message----- >From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]=20 >Sent: Tuesday, October 18, 2005 6:40 PM >To: Roger Marshall; ECRIT >Subject: RE: [ECRIT]: Caller Identity requirements:=20 >replacement text for emptysection in ECRIT req doc.=20 > >Hi Roger, > >With req 2, I am not sure how you declare that something must=20 >be supported, but at the same time say that it is out of=20 >scope. I am also not sure that I understand how this is a=20 >routing requirement. Will req 1 suffice with what you are=20 >trying to achieve? Yes, I think req-1 ought to suffice. Therefore req-2 deleted. > >Req 3, is it the responsibility of the ECRIT protocol to=20 >provide the capability to make the association, or is it the=20 >responsibility of the ECRIT protocol to support the transport=20 >of parameters such that some other node may be able to make=20 >this association. To my mind there is a difference. I agree. I have rewritten req-3 as follows: "Req3: The ECRIT protocol MUST support the transport of parameters=20 which can be used by PSAPs to associate individual call location=20 information with external caller identity records." Does this work? Roger Marshall. > >Cheers >James > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf >Of >> Roger Marshall >> Sent: Wednesday, 19 October 2005 9:42 AM >> To: ECRIT >> Subject: [ECRIT]: Caller Identity requirements: replacement text for=20 >> emptysection in ECRIT req doc. >>=20 >> All: >> There has been a placeholder within the ECRIT requirements draft >titled, >> "Emergency Caller Identification". Since this section was requested=20 >> back on 8/09, I guess I'll take a crack at submitting some=20 >(proposed)=20 >> text for it (below): >>=20 >>=20 >> "When a person places an emergency call to a PSAP, existing=20 >emergency=20 >> service messaging conveys associated caller information in=20 >addition to=20 >> receiving the caller's voice. This additional information typically=20 >> consists of a call-back number, and the caller's location=20 >(referred to=20 >> as ANI and ALI, for North American systems)." >>=20 >> "Some systems use the received callback number to perform a identity=20 >> lookup via a database lookup service, and then use the location=20 >> information received to help verify the caller's identity presented >both >> via voice, as well as the external data presented from the identity=20 >> database query. These external mechanisms are important for many=20 >> reasons, including helping callers who cannot, or will not speak, to=20 >> prevent false information from impeding appropriate dispatch=20 >> instructions and procedures, and ultimately to enable faster response >in >> the offering of help." >>=20 >> "IP-based emergency systems in the future may be able to offer even >more >> information about the caller, to help establish personal=20 >identity, but=20 >> also for today, for near-term implementations, need to provide the >same >> minimum level of identitifcation support as in the existing legacy=20 >> emergency systems." >>=20 >> "Req1: A "Call-back" number MUST be supplied within the call=20 >signaling=20 >> for each emergency call sent to the PSAP. The ECRIT protocol may=20 >> provide this number in the form of a tel:uri, a sip:uri, or an=20 >> IP-Address." >>=20 >> "Req2: The ECRIT protocol MUST support the ability for the PSAP to=20 >> perform caller identity lookup based on the tel:uri, sip:uri, or IP=20 >> Address provided with call signaling. (A variety of competing >directory >> lookup services may exist, but is not discussed in detail here, as it >is >> out of scope of this document.)" >>=20 >> "Req3: The ECRIT protocol MUST support the ability to associate=20 >> individual call location information with external caller identity=20 >> records." >>=20 >>=20 >>=20 >> I have attempted to steer clear of obvious privacy >concerns/objections, >> modeling this after what's available today in ES, but there are more=20 >> details that some may want to tease out. >>=20 >> Comments? >>=20 >> Roger Marshall. >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > >--------------------------------------------------------------- >--------------------------------- >This message is for the designated recipient only and may=20 >contain privileged, proprietary, or otherwise private information. =20 >If you have received it in error, please notify the sender=20 >immediately and delete the original. Any unauthorized use of=20 >this email is prohibited. >--------------------------------------------------------------- >--------------------------------- >[mf2] > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 19 13:26:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESHiL-0005FZ-O9; Wed, 19 Oct 2005 13:26:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESHiH-0005FK-OL for ecrit@megatron.ietf.org; Wed, 19 Oct 2005 13:26:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29995 for ; Wed, 19 Oct 2005 13:26:44 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESHu1-0001vx-5A for ecrit@ietf.org; Wed, 19 Oct 2005 13:39:04 -0400 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j9JHQisw010403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Oct 2005 13:26:44 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id j9JHQeFn030608; Wed, 19 Oct 2005 13:26:44 -0400 Message-ID: <435681CE.5010702@cs.columbia.edu> Date: Wed, 19 Oct 2005 13:26:38 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roger Marshall Subject: Re: [ECRIT]: Caller Identity requirements: replacement text for emptysection in ECRIT req doc. References: <8C837214C95C864C9F34F3635C2A6575035F6726@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A6575035F6726@SEA-EXCHVS-2.telecomsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Why wouldn't this identifier just be a SIP URI, for example? (Or whatever protocol(s) were used to reach the PSAP.) I think using IP addresses just misses the point. Roger Marshall wrote: > Michael: > It seems that the PSAP needs to know which type of service (application) > that the caller could be used to contact the call initiator. For > example, if the ECRIT protocol provided an IP Address as the "call-back" > number, the protocol SHOULD (or MUST?) provide an indicator as to which > application is to be used to target this IP Address (e.g. IM, email, > VoIP, etc.). > > Does this get close to addressing the question you're asking? > > Roger Marshall. > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 19 13:36:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESHrV-0007lg-4L; Wed, 19 Oct 2005 13:36:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESHrR-0007hN-KP for ecrit@megatron.ietf.org; Wed, 19 Oct 2005 13:36:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00495 for ; Wed, 19 Oct 2005 13:36:12 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESI3D-0002CH-Sa for ecrit@ietf.org; Wed, 19 Oct 2005 13:48:32 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 19 Oct 2005 10:36:12 -0700 X-IronPort-AV: i="3.97,231,1125903600"; d="scan'208"; a="221690506:sNHT268784690" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9JHa994015294; Wed, 19 Oct 2005 10:36:10 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Oct 2005 13:36:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ECRIT]: Caller Identity requirements: replacement text for emptysection in ECRIT req doc. Date: Wed, 19 Oct 2005 13:36:02 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3AE61AB@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [ECRIT]: Caller Identity requirements: replacement text for emptysection in ECRIT req doc. Thread-Index: AcXT3Y4AM/FQSqnNRaiWsmbORCxXIgAWwzzAACKbYwAAAvo3YAABB0/w From: "Michael Hammer \(mhammer\)" To: "Roger Marshall" , "ECRIT" X-OriginalArrivalTime: 19 Oct 2005 17:36:03.0486 (UTC) FILETIME=[93EC6BE0:01C5D4D3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Yes, that helps. It could also be an IP address embedded in a sip URI in the form of a Contact, but I didn't want to presume too much. I don't know if the call-back types need to be enumerated here or these are just used as examples. Mike > -----Original Message----- > From: Roger Marshall [mailto:RMarshall@telecomsys.com]=20 > Sent: Wednesday, October 19, 2005 1:09 PM > To: Michael Hammer (mhammer); ECRIT > Subject: RE: [ECRIT]: Caller Identity requirements:=20 > replacement text for emptysection in ECRIT req doc.=20 >=20 > Michael: > It seems that the PSAP needs to know which type of service=20 > (application) that the caller could be used to contact the=20 > call initiator. For example, if the ECRIT protocol provided=20 > an IP Address as the "call-back" > number, the protocol SHOULD (or MUST?) provide an indicator=20 > as to which application is to be used to target this IP=20 > Address (e.g. IM, email, VoIP, etc.). >=20 > Does this get close to addressing the question you're asking? >=20 > Roger Marshall. >=20 > >-----Original Message----- > >From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > >Sent: Wednesday, October 19, 2005 8:43 AM > >To: Roger Marshall; ECRIT > >Subject: RE: [ECRIT]: Caller Identity requirements:=20 > >replacement text for emptysection in ECRIT req doc.=20 > > > >Roger, > > > >In Req-1, you mention an IP address as a call-back number. Is there=20 > >some assumed higher level protocol that will be used with that IP=20 > >address? What will the PSAP operator do with it? > > > >Mike > > > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf > >> Of Roger Marshall > >> Sent: Tuesday, October 18, 2005 7:42 PM > >> To: ECRIT > >> Subject: [ECRIT]: Caller Identity requirements:=20 > replacement text for=20 > >> emptysection in ECRIT req doc. > >>=20 > >> All: > >> There has been a placeholder within the ECRIT requirements draft=20 > >> titled, "Emergency Caller Identification". Since this section was=20 > >> requested back on 8/09, I guess I'll take a crack at=20 > submitting some > >> (proposed) text for it (below): > >>=20 > >>=20 > >> "When a person places an emergency call to a PSAP, existing > >emergency > >> service messaging conveys associated caller information in > >addition to > >> receiving the caller's voice. > >> This additional information typically consists of a > >call-back number, > >> and the caller's location (referred to as ANI and ALI, for North=20 > >> American systems)." > >>=20 > >> "Some systems use the received callback number to perform=20 > a identity=20 > >> lookup via a database lookup service, and then use the location=20 > >> information received to help verify the caller's identity=20 > presented=20 > >> both via voice, as well as the external data presented from the=20 > >> identity database query. These external mechanisms are > >important for > >> many reasons, including helping callers who cannot, or will > >not speak, > >> to prevent false information from impeding appropriate dispatch=20 > >> instructions and procedures, and ultimately to enable faster > >response > >> in the offering of help." > >>=20 > >> "IP-based emergency systems in the future may be able to=20 > offer even=20 > >> more information about the caller, to help establish personal=20 > >> identity, but also for today, for near-term=20 > implementations, need to=20 > >> provide the same minimum level of identitifcation support=20 > as in the=20 > >> existing legacy emergency systems." > >>=20 > >> "Req1: A "Call-back" number MUST be supplied within the call > >signaling > >> for each emergency call sent to the PSAP. The ECRIT protocol may=20 > >> provide this number in the form of a tel:uri, a sip:uri, or an=20 > >> IP-Address." > >>=20 > >> "Req2: The ECRIT protocol MUST support the ability for the PSAP to=20 > >> perform caller identity lookup based on the tel:uri,=20 > sip:uri, or IP=20 > >> Address provided with call signaling. (A variety of competing=20 > >> directory lookup services may exist, but is not discussed=20 > in detail=20 > >> here, as it is out of scope of this document.)" > >>=20 > >> "Req3: The ECRIT protocol MUST support the ability to associate=20 > >> individual call location information with external caller identity=20 > >> records." > >>=20 > >>=20 > >>=20 > >> I have attempted to steer clear of obvious privacy=20 > >> concerns/objections, modeling this after what's available > >today in ES, > >> but there are more details that some may want to tease out. > >>=20 > >> Comments? > >>=20 > >> Roger Marshall. > >>=20 > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ecrit > >>=20 > > >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 19 13:56:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESIAs-0001Cr-UQ; Wed, 19 Oct 2005 13:56:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESIAr-0001Cm-91 for ecrit@megatron.ietf.org; Wed, 19 Oct 2005 13:56:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02069 for ; Wed, 19 Oct 2005 13:56:15 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESIMb-0002vo-Ei for ecrit@ietf.org; Wed, 19 Oct 2005 14:08:36 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Wed, 19 Oct 2005 13:56:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ECRIT]: Caller Identity requirements: replacement text for emptysection in ECRIT req doc. Date: Wed, 19 Oct 2005 10:56:11 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A6575035F67FF@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [ECRIT]: Caller Identity requirements: replacement text for emptysection in ECRIT req doc. Thread-Index: AcXT3Y4AM/FQSqnNRaiWsmbORCxXIgAWwzzAACKbYwAAAvo3YAABB0/wAAAx2+A= From: "Roger Marshall" To: "Michael Hammer \(mhammer\)" , "ECRIT" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Michael: Henning suggests using SIP:URI alone. I like this, since it makes it avoids the issue of IP Address specifically, (and yet doesn't preclude it, since I've written it as "should be in the form of a sip:uri". Given no objection, I've deleted my orig. req-2 (req-1 covers it), and for 1 & 3, we now have: Req1. call-back uri. Req1: A "call-back" number MUST=20 be supplied within the call signaling for each emergency call sent to the=20 PSAP. The ECRIT protocol should provide this number in the form of a=20 sip:uri. Req3. call identity parameters. The ECRIT protocol=20 MUST support the transport of parameters which can be used by PSAPs=20 to associate individual call location information with external caller identity=20 records. Roger Marshall. >-----Original Message----- >From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 >Sent: Wednesday, October 19, 2005 10:36 AM >To: Roger Marshall; ECRIT >Subject: RE: [ECRIT]: Caller Identity requirements:=20 >replacement text for emptysection in ECRIT req doc.=20 > >Yes, that helps. It could also be an IP address embedded in a=20 >sip URI in the form of a Contact, but I didn't want to presume=20 >too much. I don't know if the call-back types need to be=20 >enumerated here or these are just used as examples. > >Mike > >> -----Original Message----- >> From: Roger Marshall [mailto:RMarshall@telecomsys.com] >> Sent: Wednesday, October 19, 2005 1:09 PM >> To: Michael Hammer (mhammer); ECRIT >> Subject: RE: [ECRIT]: Caller Identity requirements:=20 >> replacement text for emptysection in ECRIT req doc.=20 >>=20 >> Michael: >> It seems that the PSAP needs to know which type of service >> (application) that the caller could be used to contact the call=20 >> initiator. For example, if the ECRIT protocol provided an=20 >IP Address=20 >> as the "call-back" >> number, the protocol SHOULD (or MUST?) provide an indicator as to=20 >> which application is to be used to target this IP Address (e.g. IM,=20 >> email, VoIP, etc.). >>=20 >> Does this get close to addressing the question you're asking? >>=20 >> Roger Marshall. >>=20 >> >-----Original Message----- >> >From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] >> >Sent: Wednesday, October 19, 2005 8:43 AM >> >To: Roger Marshall; ECRIT >> >Subject: RE: [ECRIT]: Caller Identity requirements:=20 >> >replacement text for emptysection in ECRIT req doc.=20 >> > >> >Roger, >> > >> >In Req-1, you mention an IP address as a call-back number. =20 >Is there=20 >> >some assumed higher level protocol that will be used with that IP=20 >> >address? What will the PSAP operator do with it? >> > >> >Mike >> > >> >> -----Original Message----- >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> >On Behalf >> >> Of Roger Marshall >> >> Sent: Tuesday, October 18, 2005 7:42 PM >> >> To: ECRIT >> >> Subject: [ECRIT]: Caller Identity requirements:=20 >> replacement text for >> >> emptysection in ECRIT req doc. >> >>=20 >> >> All: >> >> There has been a placeholder within the ECRIT requirements draft=20 >> >> titled, "Emergency Caller Identification". Since this=20 >section was=20 >> >> requested back on 8/09, I guess I'll take a crack at >> submitting some >> >> (proposed) text for it (below): >> >>=20 >> >>=20 >> >> "When a person places an emergency call to a PSAP, existing >> >emergency >> >> service messaging conveys associated caller information in >> >addition to >> >> receiving the caller's voice. >> >> This additional information typically consists of a >> >call-back number, >> >> and the caller's location (referred to as ANI and ALI, for North=20 >> >> American systems)." >> >>=20 >> >> "Some systems use the received callback number to perform >> a identity >> >> lookup via a database lookup service, and then use the location=20 >> >> information received to help verify the caller's identity >> presented >> >> both via voice, as well as the external data presented from the=20 >> >> identity database query. These external mechanisms are >> >important for >> >> many reasons, including helping callers who cannot, or will >> >not speak, >> >> to prevent false information from impeding appropriate dispatch=20 >> >> instructions and procedures, and ultimately to enable faster >> >response >> >> in the offering of help." >> >>=20 >> >> "IP-based emergency systems in the future may be able to >> offer even >> >> more information about the caller, to help establish personal=20 >> >> identity, but also for today, for near-term >> implementations, need to >> >> provide the same minimum level of identitifcation support >> as in the >> >> existing legacy emergency systems." >> >>=20 >> >> "Req1: A "Call-back" number MUST be supplied within the call >> >signaling >> >> for each emergency call sent to the PSAP. The ECRIT protocol may=20 >> >> provide this number in the form of a tel:uri, a sip:uri, or an=20 >> >> IP-Address." >> >>=20 >> >> "Req2: The ECRIT protocol MUST support the ability for=20 >the PSAP to=20 >> >> perform caller identity lookup based on the tel:uri, >> sip:uri, or IP >> >> Address provided with call signaling. (A variety of competing=20 >> >> directory lookup services may exist, but is not discussed >> in detail >> >> here, as it is out of scope of this document.)" >> >>=20 >> >> "Req3: The ECRIT protocol MUST support the ability to associate=20 >> >> individual call location information with external caller=20 >identity=20 >> >> records." >> >>=20 >> >>=20 >> >>=20 >> >> I have attempted to steer clear of obvious privacy=20 >> >> concerns/objections, modeling this after what's available >> >today in ES, >> >> but there are more details that some may want to tease out. >> >>=20 >> >> Comments? >> >>=20 >> >> Roger Marshall. >> >>=20 >> >> _______________________________________________ >> >> Ecrit mailing list >> >> Ecrit@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/ecrit >> >>=20 >> > >>=20 > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 19 14:39:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESIqV-0004Y3-Ml; Wed, 19 Oct 2005 14:39:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESIqT-0004SB-Vg for ecrit@megatron.ietf.org; Wed, 19 Oct 2005 14:39:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05859 for ; Wed, 19 Oct 2005 14:39:14 -0400 (EDT) Received: from dnsmx1pya.telcordia.com ([128.96.20.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESJ2E-0004iv-Ok for ecrit@ietf.org; Wed, 19 Oct 2005 14:51:35 -0400 Received: from rrc-its-ieg01.cc.telcordia.com (rrc-its-ieg01.cc.telcordia.com [128.96.109.78]) by dnsmx1pya.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id j9JIdDj08100 for ; Wed, 19 Oct 2005 14:39:13 -0400 (EDT) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by rrc-its-ieg01.cc.telcordia.com (SMSSMTP 4.0.5.66) with SMTP id M2005101914390913499 for ; Wed, 19 Oct 2005 14:39:09 -0400 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 19 Oct 2005 14:38:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Oct 2005 14:39:17 -0400 Message-ID: Thread-Topic: Comment on Security Threats Draft: Single IP source as potential DoS indication Thread-Index: AcXU3GvXdupkvNUZRcOQ0IjzH2S6iw== From: "Haluska, John J" To: X-OriginalArrivalTime: 19 Oct 2005 18:38:52.0852 (UTC) FILETIME=[5AA40740:01C5D4DC] X-Spam-Score: 0.5 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Subject: [Ecrit] Comment on Security Threats Draft: Single IP source as potential DoS indication X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0566457778==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0566457778== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D4DC.697B8291" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D4DC.697B8291 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 There are several places (4.2.1.1 and 4.3.1.1) in draft-taylor-ecrit-security-threats-00.txt where the origination of a large number of emergency calls or mapping queries from a single IP address is equated with a potential DoS attack. I would suggest that there should be a caveat here that _sometimes_ this is perfectly legitimate.=20 =20 For example, an emergency could occur in an office building where a single large device handles many lines, then all the signaling and media could come from the same IP address for all the calls. Or a Call Agent (e.g. PacketCable CMS in a cable MSO) handling many subscriber lines might utilize an all-IP emergency service, then all mapping queries and signaling might come from the same address, and some large media gateway or session border controller might generate lots of media streams with the same source IP address. =20 =20 =20 =20 =20 ------_=_NextPart_001_01C5D4DC.697B8291 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

There are several places (4.2.1.1 and 4.3.1.1) in = draft-taylor-ecrit-security-threats-00.txt where the origination of a large number of emergency calls or mapping = queries from a single IP address is equated with a potential DoS attack. I would suggest that there should be a caveat here that _sometimes_ this is perfectly legitimate. =

 

For example, an emergency could occur in an office = building where a single large device handles many lines, then all the signaling = and media could come from the same IP address for all the calls. Or a Call = Agent (e.g. PacketCable CMS in a cable MSO) handling many subscriber lines might = utilize an all-IP emergency service, then all mapping queries and signaling might = come from the same address, and some large media gateway or session border controller  might generate lots of media streams with the same = source IP address.

 

 

 

 

 

=00 ------_=_NextPart_001_01C5D4DC.697B8291-- --===============0566457778== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0566457778==-- From ecrit-bounces@ietf.org Wed Oct 19 18:53:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESMoi-0008HC-A7; Wed, 19 Oct 2005 18:53:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESMoh-0008H6-Ed for ecrit@megatron.ietf.org; Wed, 19 Oct 2005 18:53:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11244 for ; Wed, 19 Oct 2005 18:53:42 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESN0W-0002ss-BZ for ecrit@ietf.org; Wed, 19 Oct 2005 19:06:05 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j9JMrVY6012123; Wed, 19 Oct 2005 15:53:31 -0700 Received: from [129.46.225.108] (carbuncle.qualcomm.com [129.46.225.108]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j9JMrSld011870; Wed, 19 Oct 2005 15:53:29 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <8C837214C95C864C9F34F3635C2A6575035F67FF@SEA-EXCHVS-2.telecomsys.com> References: <8C837214C95C864C9F34F3635C2A6575035F67FF@SEA-EXCHVS-2.telecomsys.com> Date: Wed, 19 Oct 2005 15:53:27 -0700 To: "Roger Marshall" , "Michael Hammer \(mhammer\)" , "ECRIT" From: Ted Hardie Subject: RE: [ECRIT]: Caller Identity requirements: replacement text for emptysection in ECRIT req doc. Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 10:56 AM -0700 10/19/05, Roger Marshall wrote: >Michael: >Henning suggests using SIP:URI alone. I like this, since it makes it >avoids the issue of IP Address specifically, (and yet doesn't preclude >it, since I've written it as "should be in the form of a sip:uri". I would strongly prefer "in the form of a URI appropriate to the method used to contact the PSAP". We've already seen cases where non-voice methods have been successful in reach emergency workers where voice did not get through; if those were to use, say, an sms: URI then an sms: URI would be the appropriate contact for the reverse. A very recent U.S. example found here: http://www.nwanews.com/story.php?paper=adg§ion=News&storyid=133545 Ted >Given no objection, I've deleted my orig. req-2 (req-1 covers it), and >for 1 & 3, we now have: > >Req1. call-back uri. Req1: A "call-back" number MUST >be supplied within the call signaling for each emergency call sent to >the >PSAP. The ECRIT protocol should provide this number in the form of a >sip:uri. > >Req3. call identity parameters. The ECRIT protocol >MUST support the transport of parameters which can be used by PSAPs >to associate individual call location information with external caller >identity >records. > > >Roger Marshall. > >>-----Original Message----- >>From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] >>Sent: Wednesday, October 19, 2005 10:36 AM >>To: Roger Marshall; ECRIT >>Subject: RE: [ECRIT]: Caller Identity requirements: >>replacement text for emptysection in ECRIT req doc. >> >>Yes, that helps. It could also be an IP address embedded in a >>sip URI in the form of a Contact, but I didn't want to presume >>too much. I don't know if the call-back types need to be >>enumerated here or these are just used as examples. >> >>Mike >> >>> -----Original Message----- >>> From: Roger Marshall [mailto:RMarshall@telecomsys.com] >>> Sent: Wednesday, October 19, 2005 1:09 PM >>> To: Michael Hammer (mhammer); ECRIT >>> Subject: RE: [ECRIT]: Caller Identity requirements: >>> replacement text for emptysection in ECRIT req doc. >>> >>> Michael: >>> It seems that the PSAP needs to know which type of service >>> (application) that the caller could be used to contact the call >>> initiator. For example, if the ECRIT protocol provided an >>IP Address >>> as the "call-back" >>> number, the protocol SHOULD (or MUST?) provide an indicator as to >>> which application is to be used to target this IP Address (e.g. IM, >>> email, VoIP, etc.). >>> >>> Does this get close to addressing the question you're asking? >>> >>> Roger Marshall. >>> >>> >-----Original Message----- >>> >From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] >>> >Sent: Wednesday, October 19, 2005 8:43 AM >>> >To: Roger Marshall; ECRIT >>> >Subject: RE: [ECRIT]: Caller Identity requirements: >>> >replacement text for emptysection in ECRIT req doc. >>> > >>> >Roger, >>> > >>> >In Req-1, you mention an IP address as a call-back number. >>Is there >>> >some assumed higher level protocol that will be used with that IP >>> >address? What will the PSAP operator do with it? >>> > >>> >Mike >>> > >>> >> -----Original Message----- >>> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>> >On Behalf >>> >> Of Roger Marshall >>> >> Sent: Tuesday, October 18, 2005 7:42 PM >>> >> To: ECRIT >>> >> Subject: [ECRIT]: Caller Identity requirements: >>> replacement text for >>> >> emptysection in ECRIT req doc. >>> >> >>> >> All: >>> >> There has been a placeholder within the ECRIT requirements draft >>> >> titled, "Emergency Caller Identification". Since this >>section was >>> >> requested back on 8/09, I guess I'll take a crack at >>> submitting some >>> >> (proposed) text for it (below): >>> >> >>> >> >>> >> "When a person places an emergency call to a PSAP, existing >>> >emergency >>> >> service messaging conveys associated caller information in > >> >addition to >>> >> receiving the caller's voice. >>> >> This additional information typically consists of a >>> >call-back number, >>> >> and the caller's location (referred to as ANI and ALI, for North >>> >> American systems)." >>> >> >>> >> "Some systems use the received callback number to perform >>> a identity >>> >> lookup via a database lookup service, and then use the location >>> >> information received to help verify the caller's identity >>> presented >>> >> both via voice, as well as the external data presented from the >>> >> identity database query. These external mechanisms are >>> >important for >>> >> many reasons, including helping callers who cannot, or will >>> >not speak, >>> >> to prevent false information from impeding appropriate dispatch >>> >> instructions and procedures, and ultimately to enable faster >>> >response >>> >> in the offering of help." >>> >> >>> >> "IP-based emergency systems in the future may be able to >>> offer even >>> >> more information about the caller, to help establish personal >>> >> identity, but also for today, for near-term >>> implementations, need to >>> >> provide the same minimum level of identitifcation support >>> as in the >>> >> existing legacy emergency systems." >>> >> >>> >> "Req1: A "Call-back" number MUST be supplied within the call >>> >signaling >>> >> for each emergency call sent to the PSAP. The ECRIT protocol may >>> >> provide this number in the form of a tel:uri, a sip:uri, or an >>> >> IP-Address." >>> >> >>> >> "Req2: The ECRIT protocol MUST support the ability for >>the PSAP to >>> >> perform caller identity lookup based on the tel:uri, >>> sip:uri, or IP >>> >> Address provided with call signaling. (A variety of competing >>> >> directory lookup services may exist, but is not discussed >>> in detail >>> >> here, as it is out of scope of this document.)" >>> >> >>> >> "Req3: The ECRIT protocol MUST support the ability to associate >>> >> individual call location information with external caller >>identity >>> >> records." >>> >> >>> >> >>> >> >>> >> I have attempted to steer clear of obvious privacy >>> >> concerns/objections, modeling this after what's available >>> >today in ES, >>> >> but there are more details that some may want to tease out. >>> >> >>> >> Comments? >>> >> >>> >> Roger Marshall. >>> >> >>> >> _______________________________________________ >>> >> Ecrit mailing list >>> >> Ecrit@ietf.org >>> >> https://www1.ietf.org/mailman/listinfo/ecrit >>> >> >>> > >>> >> > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 19 19:18:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESNCG-0004oU-U3; Wed, 19 Oct 2005 19:18:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESNCF-0004na-09 for ecrit@megatron.ietf.org; Wed, 19 Oct 2005 19:18:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20480 for ; Wed, 19 Oct 2005 19:18:01 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESNO2-0006Hz-0j for ecrit@ietf.org; Wed, 19 Oct 2005 19:30:24 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Wed, 19 Oct 2005 19:17:57 -0400 Content-class: urn:content-classes:message Subject: RE: [Ecrit] Text for I7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Oct 2005 16:17:55 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A6575035F6C7D@SEA-EXCHVS-2.telecomsys.com> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: [Ecrit] Text for I7 Thread-Index: AcVbsALZkh1dj3P6RfGFzFMZn5VDyx5UwR0g From: "Roger Marshall" To: "Brian Rosen" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian: Please reference issue #17 on the issue tracker, at: http://www.ietf-ecrit.org:8080/ecrit-req/ Can you specify some add'l detail for this requirement? Roger Marshall. >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Brian Rosen >Sent: Wednesday, May 18, 2005 6:47 AM >To: ecrit@ietf.org >Subject: [Ecrit] Text for I7 > >I7. Traceable resolution: The entity requesting mapping=20 >SHOULD be able to definitively and securely determine the=20 >entity or entities who provided the emergency address=20 >resolution information. > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 19 19:26:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESNKV-0000PL-9q; Wed, 19 Oct 2005 19:26:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESNKU-0000Nt-At for ecrit@megatron.ietf.org; Wed, 19 Oct 2005 19:26:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24886 for ; Wed, 19 Oct 2005 19:26:32 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESNWI-0007p7-GJ for ecrit@ietf.org; Wed, 19 Oct 2005 19:38:56 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id for ; Wed, 19 Oct 2005 19:25:46 -0400 Content-class: urn:content-classes:message Subject: RE: [Ecrit] Issue 15 (civic location validation) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Oct 2005 16:25:45 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A6575035F6C98@SEA-EXCHVS-2.telecomsys.com> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: [Ecrit] Issue 15 (civic location validation) Thread-Index: AcVbsALZkh1dj3P6RfGFzFMZn5VDyx5U3WDg From: "Roger Marshall" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org A couple of questions around validation to revisit (from 9/14). This needs an answer, one way or the other - in light of needing to publish the next ECRIT requirements draft version. The item below is listed as critical within the ECRIT issue-tracker, (issue 15)=20 at: http://www.ietf-ecrit.org:8080/ecrit-req/ L6. Validation of civic location: It MUST be possible to validate an address=20 prior to its use in an actual emergency call. # is this a protocol requirement or an architecture requirement?=20 # when should this validation take place?=20 Please comment on the above two questions. Thanks. Roger Marshall. >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Brian Rosen >Sent: Wednesday, May 18, 2005 6:47 AM >To: ecrit@ietf.org >Subject: [Ecrit] Text for I7 > >I7. Traceable resolution: The entity requesting mapping=20 >SHOULD be able to definitively and securely determine the=20 >entity or entities who provided the emergency address=20 >resolution information. > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 19 19:44:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESNc2-0001DG-PV; Wed, 19 Oct 2005 19:44:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESNc2-0001Cw-3T for ecrit@megatron.ietf.org; Wed, 19 Oct 2005 19:44:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26090 for ; Wed, 19 Oct 2005 19:44:37 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESNnl-0008RQ-Qy for ecrit@ietf.org; Wed, 19 Oct 2005 19:57:00 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id for ; Wed, 19 Oct 2005 19:44:34 -0400 Content-class: urn:content-classes:message Subject: RE: [Ecrit] Open issues updated status MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Oct 2005 16:44:33 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A6575035F6CD6@SEA-EXCHVS-2.telecomsys.com> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: RE: [Ecrit] Open issues updated status Thread-Index: AcXVBw7BvQ7g4ICTTkuEpJ1fJpvadg== From: "Roger Marshall" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Below is a status update of the open issues logged against the ECRIT requirements document: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-00.txt No. Issue Description Marked Status 18 Terminology - Address Done 17 I7: Who provides the address resolution? None 15 Validation of civic location address None 3 Performance and Reliability Considerations section Done 4 Terminology - emergency address Done 2 Terminology for 'Miniumum Connectivity' None 20 WGS-84 datum, should or must? Done 19 Terminology - Civic Address Done 16 Routing a call to a database Done 12 Requirement I4 Done 11 Terminology - "Basic Emergency Service" None 10 Design of Non-Emergency Components None 9 Static vs. Dynamic Mapping None 8 Addition of New Emergency Identifiers None 7 List of Universal Identifiers None 6 Adhoc Emergency Identifiers None 5 Recognition of Multiple Universal Identifiers None 14 Missing References None 13 Relationship to RFC 3693 None The detail of each issue is listed at: http://www.ietf-ecrit.org:8080/ecrit-req/ Please post comments (w/suggested resolution) to the list for any of these marked "None", in order to move the requirements draft forward. Thanks. Roger Marshall. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 19 20:32:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESOMA-0007uj-06; Wed, 19 Oct 2005 20:32:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESOM7-0007ua-QU for ecrit@megatron.ietf.org; Wed, 19 Oct 2005 20:32:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28705 for ; Wed, 19 Oct 2005 20:32:18 -0400 (EDT) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESOXx-0001Jv-QX for ecrit@ietf.org; Wed, 19 Oct 2005 20:44:42 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Oct 2005 19:32:10 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 19 Oct 2005 19:32:09 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Oct 2005 19:32:09 -0500 Message-ID: From: "Winterbottom, James" To: "Marc Linsner" , "Tom-PT Taylor" Date: Wed, 19 Oct 2005 19:32:07 -0500 Subject: RE: [Ecrit] Proposed Requirement MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 20 Oct 2005 00:32:09.0245 (UTC) FILETIME=[B4ACECD0:01C5D50D] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Proposed Requirement Thread-Index: AcW9I8rqnUuW1BbARweSYy/NHW97fQBFOG6ABTdF/7AAFtKu4AAckN7QAEnvEkA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Marc, Thank you for your response. If what you propose below is true, and that the LCMS is not a location recipient in the sense of RFC-3693, I am assuming that no-association between location and the user must be possible. Can you confirm this? If this is the case then it really needs to be a requirement in Roger's draft, otherwise the argument does not carry the weight that you purport. Further to this, if the PIDF-LO contains a ruleset or ruleset URI, the proxy MUST not provide the location information to the LCMS unless the ruleset indicates that it is okay. This is exactly the same basis for location being provided for location-by-reference, so if it is okay to do this for by-value, then it MUST be okay to do it for by-reference. A note of warning, if the LCMS MUST not be able to associate location with user identity, then sending a PIDF-LO to the LCMS where the value for the presentity parameter is traceable to the user's true identity will be not acceptable. This implies that the proxy will need to understand this. Cheers James =20 > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Tuesday, 18 October 2005 11:28 PM > To: Winterbottom, James; 'Tom-PT Taylor' > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Proposed Requirement >=20 > James, >=20 > I believe we need to view the VSP, the LCMS service, and the PSAP as three > separate entities with no relationship between them. I also agree with > you > that in *some* cases, the PSAP will be the entity that operates the LCMS, > but from an architectual point of view, I don't believe we should depend > on > that in 100% of the cases. Therefore, we cannot make assumptions that > privacy rules, as determined by the rule-maker with respect to a PSAP, can > be extended to the LCMS service. >=20 > I believe it's reasonable to view the LCMS service simply as an 'aid' to > the > session initiation process, similar to a 'dial plan'. With this view, the > LCMS service will simply match location data to a URI, and will not be a > true Location Recipient as defined in RFC3693 (no user identified, etc.). > This obviously needs further discussion within the GeoPriv realm as we > work > through the ecrit protocol. >=20 > So, dereference any location-by-reference prior to submitting to the LCMS > service, the protocol is easy, quick, clean and covers all cases. >=20 > Thanks, >=20 > -Marc- >=20 >=20 > > -----Original Message----- > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: Monday, October 17, 2005 7:33 PM > > To: Marc Linsner; Tom-PT Taylor > > Cc: ecrit@ietf.org > > Subject: RE: [Ecrit] Proposed Requirement > > > > Hi Marc, > > > > I understand the argument, and I think that it is well put in > > that sense. > > If the VSP has to do the locationURI dereference and pass the > > location to the lcms then short of the VSP being a B2BUA and > > inserting the location into the SIP body, access to location > > from a PSAP will be required via the locationURI anyway. > > > > Do you see that the lcms are likely to be operated by the > > PSAPs, or at the very least have the services contracted to > > them by the PSAPs? If so then I don't see why the suggested > > authority can't be delegated in this situation. My point here > > to is that if you make a call and do not have a relationship > > with a VSP, it is likely that the only rule you can apply is > > to the lcms or PSAP. So I think that it is still necessary to > > allow the lcms to accept a location-by-reference in place of > > a location-by-value. > > > > > > Cheers > > James > > ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 19 21:26:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESPC9-0007M0-VS; Wed, 19 Oct 2005 21:26:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESPC8-0007Ja-At for ecrit@megatron.ietf.org; Wed, 19 Oct 2005 21:26:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01527 for ; Wed, 19 Oct 2005 21:26:02 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESPNy-0002sS-U0 for ecrit@ietf.org; Wed, 19 Oct 2005 21:38:27 -0400 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j9K1Q4sw006475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Oct 2005 21:26:04 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id j9K1Q0AM031864; Wed, 19 Oct 2005 21:26:04 -0400 Message-ID: <4356F228.5@cs.columbia.edu> Date: Wed, 19 Oct 2005 21:26:00 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roger Marshall Subject: Re: [Ecrit] Issue 15 (civic location validation) References: <8C837214C95C864C9F34F3635C2A6575035F6C98@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A6575035F6C98@SEA-EXCHVS-2.telecomsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I had raised a related issue in a slightly-tangential way a few days back. I think there are two somewhat separate issues: - if validation means "is a mapping request during an actual emergency going to return a URL or an error code", then I don't see how this requires anything at all since the mapping system can't know whether it's being called in test or in a real emergency (and it shouldn't matter). - if validation means "provide an error indication and maybe hints as to how to fix the problem", there might be a difference between test and "real" operation. In "real" mode, the mapping protocol might provide a URL even if the street name can't be found if the whole town has the same PSAP. In "validation" mode, it would presumably tell the client to go fix the problem. It is not clear to me, however, that this *requires* two modes. One could simply return a warning indicator that part of the location didn't match. As I mentioned, depending on the underlying database, validation could mean anything from "your cubicle number exists" to "I don't know anything about streets, but I recognize your city". Thus, this requires more details on what we want from validation. Given that the depth of validation depends as much on the data available as on the protocol, maybe the requirement is that the protocol can perform a partial match on civic locations and, importantly, indicate when it either did not match ("no clue") or failed to match ("known not to exist") part of the location information. Henning Roger Marshall wrote: > A couple of questions around validation to revisit (from 9/14). This > needs an answer, one way or the other - in light of needing to publish > the next ECRIT requirements draft version. > > The item below is listed as critical within the ECRIT issue-tracker, > (issue 15) > at: http://www.ietf-ecrit.org:8080/ecrit-req/ > > L6. Validation of civic location: It MUST be possible to validate an > address > prior to its use in an actual emergency call. > > # is this a protocol requirement or an architecture requirement? > # when should this validation take place? > > Please comment on the above two questions. > > Thanks. > > Roger Marshall. > > >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>On Behalf Of Brian Rosen >>Sent: Wednesday, May 18, 2005 6:47 AM >>To: ecrit@ietf.org >>Subject: [Ecrit] Text for I7 >> >>I7. Traceable resolution: The entity requesting mapping >>SHOULD be able to definitively and securely determine the >>entity or entities who provided the emergency address >>resolution information. >> >> >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit >> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 19 21:57:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESPgK-00058g-JC; Wed, 19 Oct 2005 21:57:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESPgJ-00056s-0K for ecrit@megatron.ietf.org; Wed, 19 Oct 2005 21:57:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03319 for ; Wed, 19 Oct 2005 21:57:12 -0400 (EDT) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESPs9-0003rd-GZ for ecrit@ietf.org; Wed, 19 Oct 2005 22:09:37 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1ESPg3-000843-JA; Wed, 19 Oct 2005 20:57:07 -0500 From: "Brian Rosen" To: "'Roger Marshall'" , Subject: RE: [Ecrit] Issue 15 (civic location validation) Date: Wed, 19 Oct 2005 21:56:26 -0400 Message-ID: <098001c5d519$7d24ce70$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <8C837214C95C864C9F34F3635C2A6575035F6C98@SEA-EXCHVS-2.telecomsys.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcVbsALZkh1dj3P6RfGFzFMZn5VDyx5U3WDgAAU+fYA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.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: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a protocol requirement - the protocol must have a way that can be used to determine IF a mapping was needed, could one be provided, which is the same as answering the question we really care about, which would be is the location a location we know about and can dispatch responders to. The validation takes place any time before the call. The practical answer is that it takes place when an address is loaded into the Location Server (LIS). In the scheme of things, this means when you create the actual address associated with, say, a wire pair, you validate it before you put that address in the database. Then any subsequent use is okay. You have to be able to periodically revalidate, because the database undergoes slow change. NENA would like validation to be able to return things that mapping would not normally return. For example, it would be desirable if when you did a validation query, and the location did NOT validate, that you got one or more suggested alternatives for the supplied location which would be valid: I don't have a Main St, I have an East Main Street or a West Main Street or Main Ave. When you do the mapping, a failure gets you a "default route". Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: Wednesday, October 19, 2005 7:26 PM To: ecrit@ietf.org Subject: RE: [Ecrit] Issue 15 (civic location validation) A couple of questions around validation to revisit (from 9/14). This needs an answer, one way or the other - in light of needing to publish the next ECRIT requirements draft version. The item below is listed as critical within the ECRIT issue-tracker, (issue 15) at: http://www.ietf-ecrit.org:8080/ecrit-req/ L6. Validation of civic location: It MUST be possible to validate an address prior to its use in an actual emergency call. # is this a protocol requirement or an architecture requirement? # when should this validation take place? Please comment on the above two questions. Thanks. Roger Marshall. >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of Brian Rosen >Sent: Wednesday, May 18, 2005 6:47 AM >To: ecrit@ietf.org >Subject: [Ecrit] Text for I7 > >I7. Traceable resolution: The entity requesting mapping >SHOULD be able to definitively and securely determine the >entity or entities who provided the emergency address >resolution information. > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 20 07:52:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESYya-0007Yy-5U; Thu, 20 Oct 2005 07:52:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESYyW-0007W0-14 for ecrit@megatron.ietf.org; Thu, 20 Oct 2005 07:52:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05634 for ; Thu, 20 Oct 2005 07:52:38 -0400 (EDT) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESZAP-0005ff-Rc for ecrit@ietf.org; Thu, 20 Oct 2005 08:05:08 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 06:52:36 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 20 Oct 2005 06:52:35 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 06:52:35 -0500 Message-ID: From: "Winterbottom, James" To: "Roger Marshall" , "Michael Hammer \(mhammer\)" , "ECRIT" Date: Thu, 20 Oct 2005 06:52:31 -0500 Subject: RE: [ECRIT]: Caller Identity requirements: replacement text foremptysection in ECRIT req doc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 20 Oct 2005 11:52:35.0360 (UTC) FILETIME=[C2EFB200:01C5D56C] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [ECRIT]: Caller Identity requirements: replacement text foremptysection in ECRIT req doc. Thread-Index: AcXT3Y4AM/FQSqnNRaiWsmbORCxXIgAWwzzAACKbYwAAAvo3YAABB0/wAAAx2+AAJjb98A== X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I am happy with these Roger.. Thanks James > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Roger Marshall > Sent: Thursday, 20 October 2005 3:56 AM > To: Michael Hammer (mhammer); ECRIT > Subject: RE: [ECRIT]: Caller Identity requirements: replacement text > foremptysection in ECRIT req doc. >=20 > Michael: > Henning suggests using SIP:URI alone. I like this, since it makes it > avoids the issue of IP Address specifically, (and yet doesn't preclude > it, since I've written it as "should be in the form of a sip:uri". >=20 > Given no objection, I've deleted my orig. req-2 (req-1 covers it), and > for 1 & 3, we now have: >=20 > Req1. call-back uri. Req1: A "call-back" number MUST > be supplied within the call signaling for each emergency call sent to > the > PSAP. The ECRIT protocol should provide this number in the form of a > sip:uri. >=20 > Req3. call identity parameters. The ECRIT protocol > MUST support the transport of parameters which can be used by PSAPs > to associate individual call location information with external caller > identity > records. >=20 >=20 > Roger Marshall. >=20 > >-----Original Message----- > >From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > >Sent: Wednesday, October 19, 2005 10:36 AM > >To: Roger Marshall; ECRIT > >Subject: RE: [ECRIT]: Caller Identity requirements: > >replacement text for emptysection in ECRIT req doc. > > > >Yes, that helps. It could also be an IP address embedded in a > >sip URI in the form of a Contact, but I didn't want to presume > >too much. I don't know if the call-back types need to be > >enumerated here or these are just used as examples. > > > >Mike > > > >> -----Original Message----- > >> From: Roger Marshall [mailto:RMarshall@telecomsys.com] > >> Sent: Wednesday, October 19, 2005 1:09 PM > >> To: Michael Hammer (mhammer); ECRIT > >> Subject: RE: [ECRIT]: Caller Identity requirements: > >> replacement text for emptysection in ECRIT req doc. > >> > >> Michael: > >> It seems that the PSAP needs to know which type of service > >> (application) that the caller could be used to contact the call > >> initiator. For example, if the ECRIT protocol provided an > >IP Address > >> as the "call-back" > >> number, the protocol SHOULD (or MUST?) provide an indicator as to > >> which application is to be used to target this IP Address (e.g. IM, > >> email, VoIP, etc.). > >> > >> Does this get close to addressing the question you're asking? > >> > >> Roger Marshall. > >> > >> >-----Original Message----- > >> >From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > >> >Sent: Wednesday, October 19, 2005 8:43 AM > >> >To: Roger Marshall; ECRIT > >> >Subject: RE: [ECRIT]: Caller Identity requirements: > >> >replacement text for emptysection in ECRIT req doc. > >> > > >> >Roger, > >> > > >> >In Req-1, you mention an IP address as a call-back number. > >Is there > >> >some assumed higher level protocol that will be used with that IP > >> >address? What will the PSAP operator do with it? > >> > > >> >Mike > >> > > >> >> -----Original Message----- > >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >> >On Behalf > >> >> Of Roger Marshall > >> >> Sent: Tuesday, October 18, 2005 7:42 PM > >> >> To: ECRIT > >> >> Subject: [ECRIT]: Caller Identity requirements: > >> replacement text for > >> >> emptysection in ECRIT req doc. > >> >> > >> >> All: > >> >> There has been a placeholder within the ECRIT requirements draft > >> >> titled, "Emergency Caller Identification". Since this > >section was > >> >> requested back on 8/09, I guess I'll take a crack at > >> submitting some > >> >> (proposed) text for it (below): > >> >> > >> >> > >> >> "When a person places an emergency call to a PSAP, existing > >> >emergency > >> >> service messaging conveys associated caller information in > >> >addition to > >> >> receiving the caller's voice. > >> >> This additional information typically consists of a > >> >call-back number, > >> >> and the caller's location (referred to as ANI and ALI, for North > >> >> American systems)." > >> >> > >> >> "Some systems use the received callback number to perform > >> a identity > >> >> lookup via a database lookup service, and then use the location > >> >> information received to help verify the caller's identity > >> presented > >> >> both via voice, as well as the external data presented from the > >> >> identity database query. These external mechanisms are > >> >important for > >> >> many reasons, including helping callers who cannot, or will > >> >not speak, > >> >> to prevent false information from impeding appropriate dispatch > >> >> instructions and procedures, and ultimately to enable faster > >> >response > >> >> in the offering of help." > >> >> > >> >> "IP-based emergency systems in the future may be able to > >> offer even > >> >> more information about the caller, to help establish personal > >> >> identity, but also for today, for near-term > >> implementations, need to > >> >> provide the same minimum level of identitifcation support > >> as in the > >> >> existing legacy emergency systems." > >> >> > >> >> "Req1: A "Call-back" number MUST be supplied within the call > >> >signaling > >> >> for each emergency call sent to the PSAP. The ECRIT protocol may > >> >> provide this number in the form of a tel:uri, a sip:uri, or an > >> >> IP-Address." > >> >> > >> >> "Req2: The ECRIT protocol MUST support the ability for > >the PSAP to > >> >> perform caller identity lookup based on the tel:uri, > >> sip:uri, or IP > >> >> Address provided with call signaling. (A variety of competing > >> >> directory lookup services may exist, but is not discussed > >> in detail > >> >> here, as it is out of scope of this document.)" > >> >> > >> >> "Req3: The ECRIT protocol MUST support the ability to associate > >> >> individual call location information with external caller > >identity > >> >> records." > >> >> > >> >> > >> >> > >> >> I have attempted to steer clear of obvious privacy > >> >> concerns/objections, modeling this after what's available > >> >today in ES, > >> >> but there are more details that some may want to tease out. > >> >> > >> >> Comments? > >> >> > >> >> Roger Marshall. > >> >> > >> >> _______________________________________________ > >> >> Ecrit mailing list > >> >> Ecrit@ietf.org > >> >> https://www1.ietf.org/mailman/listinfo/ecrit > >> >> > >> > > >> > > >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 20 08:52:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESZuW-0006iv-12; Thu, 20 Oct 2005 08:52:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESZuU-0006in-Kp for ecrit@megatron.ietf.org; Thu, 20 Oct 2005 08:52:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08777 for ; Thu, 20 Oct 2005 08:52:28 -0400 (EDT) Received: from dnsmx1rrc.telcordia.com ([128.96.20.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESa6M-0007JX-Vk for ecrit@ietf.org; Thu, 20 Oct 2005 09:04:59 -0400 Received: from rrc-its-ieg02.cc.telcordia.com (rrc-its-ieg02.cc.telcordia.com [128.96.109.3]) by dnsmx1rrc.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id j9KCqNE07653; Thu, 20 Oct 2005 08:52:23 -0400 (EDT) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by rrc-its-ieg02.cc.telcordia.com (SMSSMTP 4.0.5.66) with SMTP id M2005102008522027723 ; Thu, 20 Oct 2005 08:52:20 -0400 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 20 Oct 2005 08:52:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Issue 15 (civic location validation) Date: Thu, 20 Oct 2005 08:52:20 -0400 Message-ID: Thread-Topic: [Ecrit] Issue 15 (civic location validation) Thread-Index: AcXVFWvZSV2gWFoSSeOiCj4pMeEl+AAXQ7lA From: "Abbott, Nadine B" To: "Henning Schulzrinne" X-OriginalArrivalTime: 20 Oct 2005 12:52:56.0612 (UTC) FILETIME=[315EE640:01C5D575] X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Henning, In the migratory work done on location validation in NENA, we allowed for several cases: - Match - Match, after some processing (e.g., adjustments in abbreviations, etc., this distinction is not so important as the next two, I think) - Ambiguous match (more than one match at some level (this would be your "known not to exist", I believe) - No match (this would be your "did not match", I believe). In the failure cases, the location validation response may return some assistance: e.g., for ambiguous match, we allow for return some of the best alternative possible matches; for ambiguous match and no match, we allow for return of a URI where more help might be available to create a valid address. I wonder if it might be possible to consider whether the mapping protocol could provide a set of similar responses, or at least provide a URI(s) for where the mapping client might go for the kind of support available in the migratory solution? The NENA migratory solution for this function uses standard Web Services protocol.=20 Is there any interest in leveraging any of this work? Thanks, Nadine Abbott -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Wednesday, October 19, 2005 9:26 PM To: Roger Marshall Cc: ecrit@ietf.org Subject: Re: [Ecrit] Issue 15 (civic location validation) I had raised a related issue in a slightly-tangential way a few days back. I think there are two somewhat separate issues: - if validation means "is a mapping request during an actual emergency=20 going to return a URL or an error code", then I don't see how this=20 requires anything at all since the mapping system can't know whether=20 it's being called in test or in a real emergency (and it shouldn't matter). - if validation means "provide an error indication and maybe hints as to how to fix the problem", there might be a difference between test and=20 "real" operation. In "real" mode, the mapping protocol might provide a=20 URL even if the street name can't be found if the whole town has the=20 same PSAP. In "validation" mode, it would presumably tell the client to=20 go fix the problem. It is not clear to me, however, that this *requires* two modes. One could simply return a warning indicator that part of the=20 location didn't match. As I mentioned, depending on the underlying=20 database, validation could mean anything from "your cubicle number=20 exists" to "I don't know anything about streets, but I recognize your city". Thus, this requires more details on what we want from validation. Given=20 that the depth of validation depends as much on the data available as on the protocol, maybe the requirement is that the protocol can perform a=20 partial match on civic locations and, importantly, indicate when it=20 either did not match ("no clue") or failed to match ("known not to=20 exist") part of the location information. Henning Roger Marshall wrote: > A couple of questions around validation to revisit (from 9/14). This=20 > needs an answer, one way or the other - in light of needing to publish > the next ECRIT requirements draft version. >=20 > The item below is listed as critical within the ECRIT issue-tracker,=20 > (issue 15) > at: http://www.ietf-ecrit.org:8080/ecrit-req/ >=20 > L6. Validation of civic location: It MUST be possible to validate an=20 > address prior to its use in an actual emergency call. >=20 > # is this a protocol requirement or an architecture requirement? > # when should this validation take place?=20 >=20 > Please comment on the above two questions. >=20 > Thanks. >=20 > Roger Marshall. >=20 >=20 >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>On Behalf Of Brian Rosen >>Sent: Wednesday, May 18, 2005 6:47 AM >>To: ecrit@ietf.org >>Subject: [Ecrit] Text for I7 >> >>I7. Traceable resolution: The entity requesting mapping >>SHOULD be able to definitively and securely determine the=20 >>entity or entities who provided the emergency address=20 >>resolution information. >> >> >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit >> >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 20 09:15:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESaGa-00076r-0O; Thu, 20 Oct 2005 09:15:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESaGY-00076k-I4 for ecrit@megatron.ietf.org; Thu, 20 Oct 2005 09:15:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09972 for ; Thu, 20 Oct 2005 09:15:20 -0400 (EDT) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESaSS-0007xW-0I for ecrit@ietf.org; Thu, 20 Oct 2005 09:27:48 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1ESaGJ-000518-RB for ecrit@ietf.org; Thu, 20 Oct 2005 08:15:16 -0500 From: "Brian Rosen" To: Date: Thu, 20 Oct 2005 09:14:33 -0400 Message-ID: <0a0001c5d578$381354f0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXUFfvaD6H+sGKmQ7StcDEkbvjgdgBYhMhQ X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.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: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] FW: NENA Comments on draft-ietf-ecrit-requirements-00 - Basis for mapping X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org More comments from NENA: We requested that a requirement be included that specified that altitude could be used in mapping.=A0 An example is a high rise where some floors = are served by a local response capability (perhaps a college campus police force) where other floors are served by the municipal police.=A0 We find = no such requirement. Actually, we think any combination of PIDF-LO fields = could be used for mapping. 13. We did not find an equivalent to our 3.6-8:=A0 Boundaries for civic routing must be able to be specific to a street address range, a side of = a street (even/odd street addresses), a building within a campus or any of = the location fields available.=A0 This is an essential requirement.=20 Similarly, 3.6-9:=A0 It must be possible to use various combined = components of the location object for determination of routing.=A0 Some areas may only require routing to a country level, others to a state/province, others = to a county, or to a municipality, and so on.=A0 No assumption should be made = on the granularity of routing boundaries or about the combination of = components used.=A0 This is particularly important in countries with less well = developed emergency calling systems.=A0 We believe everyone intends to do this, = but the requirement to do so is not stated.=20 We have discussed, in ecrit and in geopriv, the issue of a location = having a postal community name, and the actual legal community name.=A0 The = mapping function needs to be aware of this difference in one way or another.=A0 Generally, you need to be able to query with either, and if exactly one record matches, you use that for the mapping.=A0 There needs to be a way = to resolve possible conflicts where there is no single match.=A0 In our = view, this is part of the validation process.=A0 If a mapping is requested = where there is no unique match, then alternatives could be presented.=A0 You = would wish to determine this ahead of time so that a correct location was determined.=A0 Further, if you present the postal community name for = mapping, and there is exactly one match, you need to return the actual community name.=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 20 09:51:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESapU-0005Tv-Bq; Thu, 20 Oct 2005 09:51:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESapR-0005SD-7e for ecrit@megatron.ietf.org; Thu, 20 Oct 2005 09:51:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12788 for ; Thu, 20 Oct 2005 09:51:22 -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.43) id 1ESb1L-0000tM-RJ for ecrit@ietf.org; Thu, 20 Oct 2005 10:03:54 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 20 Oct 2005 06:51:19 -0700 X-IronPort-AV: i="3.97,236,1125903600"; d="scan'208"; a="667862087:sNHT27101338" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9KDojv5021035; Thu, 20 Oct 2005 06:51:15 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 06:50:54 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 06:50:53 -0700 From: "Marc Linsner" To: "'Winterbottom, James'" , "'Tom-PT Taylor'" Subject: RE: [Ecrit] Proposed Requirement Date: Thu, 20 Oct 2005 09:50:45 -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: AcW9I8rqnUuW1BbARweSYy/NHW97fQBFOG6ABTdF/7AAFtKu4AAckN7QAEnvEkAAGlZ+wA== In-Reply-To: Message-ID: X-OriginalArrivalTime: 20 Oct 2005 13:50:53.0641 (UTC) FILETIME=[49D76B90:01C5D57D] X-Spam-Score: 1.1 (+) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org James, Comments in-line.... > > Thank you for your response. > If what you propose below is true, and that the LCMS is not a > location recipient in the sense of RFC-3693, I am assuming > that no-association between location and the user must be > possible. Can you confirm this? Ecrit has yet to figure out what information a LCMS client will submit to a LCMS server. What I am asserting is user information is certainly not needed for LCMS to perform the requested task, matching location information to uri. > If this is the case then it really needs to be a requirement > in Roger's draft, otherwise the argument does not carry the > weight that you purport. I don't feel we (I) know enough to make this a requirement, yet. I'd like more opinions on the subject of what information is required at the LCMS server. > > Further to this, if the PIDF-LO contains a ruleset or ruleset > URI, the proxy MUST not provide the location information to > the LCMS unless the ruleset indicates that it is okay. This is what causes heartburn. If Joe User simply 'forgets' to include the LCMS in his ruleset (unaware that such a service is necessary to complete emergency calling), then his attempts to complete a properly-routed call will fail. So my question, is the act of matching just location (no user/host identity) to uri a breach of RFC-3693? I don't believe so, there is nothing interesting about 123 Main St. equals calltaker@psap.com. This > is exactly the same basis for location being provided for > location-by-reference, so if it is okay to do this for > by-value, then it MUST be okay to do it for by-reference. Location-by-value does not equal pidf-lo. I think this is the point I'm attempting to make: If you expect the LCMS server to dereference a location-by-reference, the LCMS server MUST be in the ruleset. Alternatively, if the proxy (LCMS client) performs dereference and uses only the location-by-value data (no user identity) then the LCMS server does not fall under the definition of location-recipient spelled out in RFC-3693. Obviously, if Joe User forgets to include his proxy in the ruleset, then the proper call-routing will fail as the proxy cannot dereference the LBR. > > A note of warning, if the LCMS MUST not be able to associate > location with user identity, then sending a PIDF-LO to the > LCMS where the value for the presentity parameter is > traceable to the user's true identity will be not acceptable. > This implies that the proxy will need to understand this. Again, the pidf-lo contains way more data than necessary for LCMS to perform it's task, IMO. Thanks, -Marc- > > Cheers > James > > > > > > -----Original Message----- > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > Sent: Tuesday, 18 October 2005 11:28 PM > > To: Winterbottom, James; 'Tom-PT Taylor' > > Cc: ecrit@ietf.org > > Subject: RE: [Ecrit] Proposed Requirement > > > > James, > > > > I believe we need to view the VSP, the LCMS service, and the PSAP as > three > > separate entities with no relationship between them. I also agree > with > > you > > that in *some* cases, the PSAP will be the entity that operates the > LCMS, > > but from an architectual point of view, I don't believe we should > depend > > on > > that in 100% of the cases. Therefore, we cannot make > assumptions that > > privacy rules, as determined by the rule-maker with respect > to a PSAP, > can > > be extended to the LCMS service. > > > > I believe it's reasonable to view the LCMS service simply > as an 'aid' > to > > the > > session initiation process, similar to a 'dial plan'. With > this view, > the > > LCMS service will simply match location data to a URI, and > will not be > a > > true Location Recipient as defined in RFC3693 (no user identified, > etc.). > > This obviously needs further discussion within the GeoPriv > realm as we > > work through the ecrit protocol. > > > > So, dereference any location-by-reference prior to submitting to the > LCMS > > service, the protocol is easy, quick, clean and covers all cases. > > > > Thanks, > > > > -Marc- > > > > > > > -----Original Message----- > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: Monday, October 17, 2005 7:33 PM > > > To: Marc Linsner; Tom-PT Taylor > > > Cc: ecrit@ietf.org > > > Subject: RE: [Ecrit] Proposed Requirement > > > > > > Hi Marc, > > > > > > I understand the argument, and I think that it is well > put in that > > > sense. > > > If the VSP has to do the locationURI dereference and pass the > > > location to the lcms then short of the VSP being a B2BUA and > > > inserting the location into the SIP body, access to > location from a > > > PSAP will be required via the locationURI anyway. > > > > > > Do you see that the lcms are likely to be operated by the > PSAPs, or > > > at the very least have the services contracted to them by > the PSAPs? > > > If so then I don't see why the suggested authority can't be > > > delegated in this situation. My point here to is that if > you make a > > > call and do not have a relationship with a VSP, it is likely that > > > the only rule you can apply is to the lcms or PSAP. So I > think that > > > it is still necessary to allow the lcms to accept a > > > location-by-reference in place of a location-by-value. > > > > > > > > > Cheers > > > James > > > > > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 20 11:17:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EScAM-0003IB-Ik; Thu, 20 Oct 2005 11:17:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EScAK-0003Hs-A4 for ecrit@megatron.ietf.org; Thu, 20 Oct 2005 11:17:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22697 for ; Thu, 20 Oct 2005 11:17:01 -0400 (EDT) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EScMH-0005QB-QH for ecrit@ietf.org; Thu, 20 Oct 2005 11:29:34 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1EScA9-0002Pq-BT for ecrit@ietf.org; Thu, 20 Oct 2005 10:17:01 -0500 From: "Brian Rosen" To: Date: Thu, 20 Oct 2005 11:15:42 -0400 Message-ID: <0a4101c5d589$24e80b30$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXUFgkgLdjmuMKwRiGnpzSRU7iXYQBcwEYg X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.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.6 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Subject: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00 - Security and Reliability X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0009634883==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0009634883== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A42_01C5D567.9DD66B30" This is a multi-part message in MIME format. ------=_NextPart_000_0A42_01C5D567.9DD66B30 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit More comments from NENA: Our requirement 3.6-16: Information and mechanisms used to determine routing must be extremely reliable and available, which implies redundancy, protocol stability, and resiliency is not adequately addressed by I8. Resilience against server failure: A client MUST be able to fail over to another replica of the mapping server, so that a failure of a server does not endanger the ability to perform the mapping. We also don't think this adequately addresses 3.8-1: There shall be no single point of failure or 3.8-3: Special consideration should be given to distributed Denial of Service of Service attacks. We recognize this is part of the security issues being covered in another document. We do not find something that covers our requirement 3.6-17: Routing information must be secured against unauthorized modification. PSAPs (or perhaps a higher level civic authority such as a county, state/province or national body) or their designated representative must be the only entities permitted to change routing information. ------=_NextPart_000_0A42_01C5D567.9DD66B30 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

More <delayed> comments from NENA:

Our requirement 3.6-16: Information and mechanisms used to = determine routing must be extremely reliable and available, which implies = redundancy, protocol stability, and resiliency is not adequately addressed by = I8.  Resilience against server failure: A client MUST be able to fail over to another replica of the mapping server, so that a failure of a server = does not endanger the ability to perform the mapping.  We also don’t = think this adequately addresses 3.8-1: There shall be no single point of = failure or 3.8-3: Special consideration should be given to distributed Denial of = Service of Service attacks.  We recognize this is part of the security = issues being covered in another document.

 

We do not find something that covers our requirement 3.6-17: = Routing information must be secured against unauthorized modification.  = PSAPs (or perhaps a higher level civic authority such as a county, state/province = or national body) or their designated representative must be the only = entities permitted to change routing information.

 

------=_NextPart_000_0A42_01C5D567.9DD66B30-- --===============0009634883== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0009634883==-- From ecrit-bounces@ietf.org Thu Oct 20 12:33:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESdM0-0004CP-2H; Thu, 20 Oct 2005 12:33:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESdLz-0004CI-7q for ecrit@megatron.ietf.org; Thu, 20 Oct 2005 12:33:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27996 for ; Thu, 20 Oct 2005 12:33:09 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESdXx-0008GV-3Y for ecrit@ietf.org; Thu, 20 Oct 2005 12:45:41 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Thu, 20 Oct 2005 12:33:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ECRIT]: Caller Identity requirements: replacement text for emptysection in ECRIT req doc. Date: Thu, 20 Oct 2005 09:33:00 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65750364548A@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [ECRIT]: Caller Identity requirements: replacement text for emptysection in ECRIT req doc. Thread-Index: AcXU//o3vfZgwnhCS9W1Yqc1f5/arQAk4H0A From: "Roger Marshall" To: "Ted Hardie" , "Michael Hammer \(mhammer\)" , "ECRIT" X-Spam-Score: 0.0 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Ted: This is a good clarification, which (I think) meets all cases. =20 Requirement is reworded as follows: Req-X. call-back uri. Req1: A "call-back" number MUST=20 be supplied within the call signaling for each emergency call sent to the=20 PSAP. The ECRIT protocol should provide this number in the form of a=20 URI appropriate to the method used to contact the PSAP. Thanks. Roger Marshall. >-----Original Message----- >From: Ted Hardie [mailto:hardie@qualcomm.com]=20 >Sent: Wednesday, October 19, 2005 3:53 PM >To: Roger Marshall; Michael Hammer (mhammer); ECRIT >Subject: RE: [ECRIT]: Caller Identity requirements:=20 >replacement text for emptysection in ECRIT req doc. > >At 10:56 AM -0700 10/19/05, Roger Marshall wrote: >>Michael: >>Henning suggests using SIP:URI alone. I like this, since it makes it=20 >>avoids the issue of IP Address specifically, (and yet doesn't=20 >preclude=20 >>it, since I've written it as "should be in the form of a sip:uri". > >I would strongly prefer "in the form of a URI appropriate to=20 >the method used to contact the PSAP". We've already seen=20 >cases where non-voice methods have been successful in reach=20 >emergency workers where voice did not get through; if those=20 >were to use, say, an sms: URI then an sms: URI would be the=20 >appropriate contact for the reverse. > >A very recent U.S. example found here:=20 > >http://www.nwanews.com/story.php?paper=3Dadg§ion=3DNews&storyid=3D13= 3545 > > Ted > > > > >>Given no objection, I've deleted my orig. req-2 (req-1 covers=20 >it), and=20 >>for 1 & 3, we now have: >> >>Req1. call-back uri. Req1: A "call-back" number MUST be supplied=20 >>within the call signaling for each emergency call sent to the PSAP. =20 >>The ECRIT protocol should provide this number in the form of=20 >a sip:uri. >> >>Req3. call identity parameters. The ECRIT protocol MUST support the=20 >>transport of parameters which can be used by PSAPs to associate=20 >>individual call location information with external caller identity=20 >>records. >> >> >>Roger Marshall. >> >>>-----Original Message----- >>>From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] >>>Sent: Wednesday, October 19, 2005 10:36 AM >>>To: Roger Marshall; ECRIT >>>Subject: RE: [ECRIT]: Caller Identity requirements: >>>replacement text for emptysection in ECRIT req doc. >>> >>>Yes, that helps. It could also be an IP address embedded in=20 >a sip URI=20 >>>in the form of a Contact, but I didn't want to presume too much. I=20 >>>don't know if the call-back types need to be enumerated here=20 >or these=20 >>>are just used as examples. >>> >>>Mike >>> >>>> -----Original Message----- >>>> From: Roger Marshall [mailto:RMarshall@telecomsys.com] >>>> Sent: Wednesday, October 19, 2005 1:09 PM >>>> To: Michael Hammer (mhammer); ECRIT >>>> Subject: RE: [ECRIT]: Caller Identity requirements: >>>> replacement text for emptysection in ECRIT req doc. >>>> >>>> Michael: >>>> It seems that the PSAP needs to know which type of service >>>> (application) that the caller could be used to contact the call=20 >>>> initiator. For example, if the ECRIT protocol provided an >>>IP Address >>>> as the "call-back" >>>> number, the protocol SHOULD (or MUST?) provide an indicator as to=20 >>>> which application is to be used to target this IP Address=20 >(e.g. IM,=20 >>>> email, VoIP, etc.). >>>> >>>> Does this get close to addressing the question you're asking? >>>> >>>> Roger Marshall. >>>> >>>> >-----Original Message----- >>>> >From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] >>>> >Sent: Wednesday, October 19, 2005 8:43 AM >>>> >To: Roger Marshall; ECRIT >>>> >Subject: RE: [ECRIT]: Caller Identity requirements: >>>> >replacement text for emptysection in ECRIT req doc. >>>> > >>>> >Roger, >>>> > >>>> >In Req-1, you mention an IP address as a call-back number.=20 >>>Is there >>>> >some assumed higher level protocol that will be used with that IP=20 >>>> >address? What will the PSAP operator do with it? >>>> > >>>> >Mike >>>> > >>>> >> -----Original Message----- >>>> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>>> >On Behalf >>>> >> Of Roger Marshall >>>> >> Sent: Tuesday, October 18, 2005 7:42 PM >>>> >> To: ECRIT >>>> >> Subject: [ECRIT]: Caller Identity requirements: >>>> replacement text for >>>> >> emptysection in ECRIT req doc. >>>> >> >>>> >> All: >>>> >> There has been a placeholder within the ECRIT=20 >requirements draft=20 >>>> >> titled, "Emergency Caller Identification". Since this >>>section was >>>> >> requested back on 8/09, I guess I'll take a crack at >>>> submitting some >>>> >> (proposed) text for it (below): >>>> >> >>>> >> >>>> >> "When a person places an emergency call to a PSAP, existing >>>> >emergency >>>> >> service messaging conveys associated caller information in >> >> >addition to >>>> >> receiving the caller's voice. >>>> >> This additional information typically consists of a >>>> >call-back number, >>>> >> and the caller's location (referred to as ANI and ALI,=20 >for North=20 >>>> >> American systems)." >>>> >> >>>> >> "Some systems use the received callback number to perform >>>> a identity >>>> >> lookup via a database lookup service, and then use the location=20 >>>> >> information received to help verify the caller's identity >>>> presented >>>> >> both via voice, as well as the external data presented from the=20 >>>> >> identity database query. These external mechanisms are >>>> >important for >>>> >> many reasons, including helping callers who cannot, or will >>>> >not speak, >>>> >> to prevent false information from impeding appropriate dispatch=20 >>>> >> instructions and procedures, and ultimately to enable faster >>>> >response >>>> >> in the offering of help." >>>> >> >>>> >> "IP-based emergency systems in the future may be able to >>>> offer even >>>> >> more information about the caller, to help establish personal=20 >>>> >> identity, but also for today, for near-term >>>> implementations, need to >>>> >> provide the same minimum level of identitifcation support >>>> as in the >>>> >> existing legacy emergency systems." >>>> >> >>>> >> "Req1: A "Call-back" number MUST be supplied within the call >>>> >signaling >>>> >> for each emergency call sent to the PSAP. The ECRIT=20 >protocol may=20 >>>> >> provide this number in the form of a tel:uri, a sip:uri, or an=20 >>>> >> IP-Address." >>>> >> >>>> >> "Req2: The ECRIT protocol MUST support the ability for >>>the PSAP to >>>> >> perform caller identity lookup based on the tel:uri, >>>> sip:uri, or IP >>>> >> Address provided with call signaling. (A variety of competing=20 >>>> >> directory lookup services may exist, but is not discussed >>>> in detail >>>> >> here, as it is out of scope of this document.)" >>>> >> >>>> >> "Req3: The ECRIT protocol MUST support the ability to=20 >associate=20 >>>> >> individual call location information with external caller >>>identity >>>> >> records." >>>> >> >>>> >> >>>> >> >>>> >> I have attempted to steer clear of obvious privacy=20 >>>> >> concerns/objections, modeling this after what's available >>>> >today in ES, >>>> >> but there are more details that some may want to tease out. >>>> >> >>>> >> Comments? >>>> >> >>>> >> Roger Marshall. >>>> >> >>>> >> _______________________________________________ >>>> >> Ecrit mailing list >>>> >> Ecrit@ietf.org >>>> >> https://www1.ietf.org/mailman/listinfo/ecrit >>>> >> >>>> > >>>> >>> >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 20 13:34:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESeJ6-0004WG-1s; Thu, 20 Oct 2005 13:34:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESeJ3-0004QY-6K for ecrit@megatron.ietf.org; Thu, 20 Oct 2005 13:34:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02247 for ; Thu, 20 Oct 2005 13:34:11 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESeV1-0001zm-Mr for ecrit@ietf.org; Thu, 20 Oct 2005 13:46:44 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 20 Oct 2005 10:34:12 -0700 X-IronPort-AV: i="3.97,236,1125903600"; d="scan'208"; a="354667033:sNHT29089760" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9KHXcK9022388; Thu, 20 Oct 2005 10:34:09 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 10:34:08 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 10:34:07 -0700 From: "Marc Linsner" To: "'Roger Marshall'" , "'Ted Hardie'" , "'Michael Hammer \(mhammer\)'" , "'ECRIT'" Subject: RE: [ECRIT]: Caller Identity requirements: replacement text foremptysection in ECRIT req doc. Date: Thu, 20 Oct 2005 13:33:59 -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: AcXU//o3vfZgwnhCS9W1Yqc1f5/arQAk4H0AAAHC9TA= In-Reply-To: <8C837214C95C864C9F34F3635C2A65750364548A@SEA-EXCHVS-2.telecomsys.com> Message-ID: X-OriginalArrivalTime: 20 Oct 2005 17:34:07.0915 (UTC) FILETIME=[79736FB0:01C5D59C] X-Spam-Score: 1.1 (+) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Sorry for not following this close enough. What is the definition of "call-back" in this context? Thanks, -Marc- > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Roger Marshall > Sent: Thursday, October 20, 2005 12:33 PM > To: Ted Hardie; Michael Hammer (mhammer); ECRIT > Subject: RE: [ECRIT]: Caller Identity requirements: > replacement text foremptysection in ECRIT req doc. > > Ted: > This is a good clarification, which (I think) meets all cases. > > Requirement is reworded as follows: > > Req-X. call-back uri. Req1: A "call-back" number MUST be > supplied within the call signaling for each emergency call > sent to the PSAP. The ECRIT protocol should provide this > number in the form of a URI appropriate to the method used to > contact the PSAP. > > Thanks. > > Roger Marshall. > > >-----Original Message----- > >From: Ted Hardie [mailto:hardie@qualcomm.com] > >Sent: Wednesday, October 19, 2005 3:53 PM > >To: Roger Marshall; Michael Hammer (mhammer); ECRIT > >Subject: RE: [ECRIT]: Caller Identity requirements: > >replacement text for emptysection in ECRIT req doc. > > > >At 10:56 AM -0700 10/19/05, Roger Marshall wrote: > >>Michael: > >>Henning suggests using SIP:URI alone. I like this, since > it makes it > >>avoids the issue of IP Address specifically, (and yet doesn't > >preclude > >>it, since I've written it as "should be in the form of a sip:uri". > > > >I would strongly prefer "in the form of a URI appropriate to > the method > >used to contact the PSAP". We've already seen cases where non-voice > >methods have been successful in reach emergency workers > where voice did > >not get through; if those were to use, say, an sms: URI then an sms: > >URI would be the appropriate contact for the reverse. > > > >A very recent U.S. example found here: > > > >http://www.nwanews.com/story.php?paper=adg§ion=News&story > id=133545 > > > > Ted > > > > > > > > > >>Given no objection, I've deleted my orig. req-2 (req-1 covers > >it), and > >>for 1 & 3, we now have: > >> > >>Req1. call-back uri. Req1: A "call-back" number MUST be supplied > >>within the call signaling for each emergency call sent to the PSAP. > >>The ECRIT protocol should provide this number in the form of > >a sip:uri. > >> > >>Req3. call identity parameters. The ECRIT protocol MUST > support the > >>transport of parameters which can be used by PSAPs to associate > >>individual call location information with external caller identity > >>records. > >> > >> > >>Roger Marshall. > >> > >>>-----Original Message----- > >>>From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > >>>Sent: Wednesday, October 19, 2005 10:36 AM > >>>To: Roger Marshall; ECRIT > >>>Subject: RE: [ECRIT]: Caller Identity requirements: > >>>replacement text for emptysection in ECRIT req doc. > >>> > >>>Yes, that helps. It could also be an IP address embedded in > >a sip URI > >>>in the form of a Contact, but I didn't want to presume too > much. I > >>>don't know if the call-back types need to be enumerated here > >or these > >>>are just used as examples. > >>> > >>>Mike > >>> > >>>> -----Original Message----- > >>>> From: Roger Marshall [mailto:RMarshall@telecomsys.com] > >>>> Sent: Wednesday, October 19, 2005 1:09 PM > >>>> To: Michael Hammer (mhammer); ECRIT > >>>> Subject: RE: [ECRIT]: Caller Identity requirements: > >>>> replacement text for emptysection in ECRIT req doc. > >>>> > >>>> Michael: > >>>> It seems that the PSAP needs to know which type of service > >>>> (application) that the caller could be used to contact the call > >>>> initiator. For example, if the ECRIT protocol provided an > >>>IP Address > >>>> as the "call-back" > >>>> number, the protocol SHOULD (or MUST?) provide an > indicator as to > >>>> which application is to be used to target this IP Address > >(e.g. IM, > >>>> email, VoIP, etc.). > >>>> > >>>> Does this get close to addressing the question you're asking? > >>>> > >>>> Roger Marshall. > >>>> > >>>> >-----Original Message----- > >>>> >From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > >>>> >Sent: Wednesday, October 19, 2005 8:43 AM > >>>> >To: Roger Marshall; ECRIT > >>>> >Subject: RE: [ECRIT]: Caller Identity requirements: > >>>> >replacement text for emptysection in ECRIT req doc. > >>>> > > >>>> >Roger, > >>>> > > >>>> >In Req-1, you mention an IP address as a call-back number. > >>>Is there > >>>> >some assumed higher level protocol that will be used > with that IP > >>>> >address? What will the PSAP operator do with it? > >>>> > > >>>> >Mike > >>>> > > >>>> >> -----Original Message----- > >>>> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >>>> >On Behalf > >>>> >> Of Roger Marshall > >>>> >> Sent: Tuesday, October 18, 2005 7:42 PM > >>>> >> To: ECRIT > >>>> >> Subject: [ECRIT]: Caller Identity requirements: > >>>> replacement text for > >>>> >> emptysection in ECRIT req doc. > >>>> >> > >>>> >> All: > >>>> >> There has been a placeholder within the ECRIT > >requirements draft > >>>> >> titled, "Emergency Caller Identification". Since this > >>>section was > >>>> >> requested back on 8/09, I guess I'll take a crack at > >>>> submitting some > >>>> >> (proposed) text for it (below): > >>>> >> > >>>> >> > >>>> >> "When a person places an emergency call to a PSAP, existing > >>>> >emergency > >>>> >> service messaging conveys associated caller information in > >> >> >addition to > >>>> >> receiving the caller's voice. > >>>> >> This additional information typically consists of a > >>>> >call-back number, > >>>> >> and the caller's location (referred to as ANI and ALI, > >for North > >>>> >> American systems)." > >>>> >> > >>>> >> "Some systems use the received callback number to perform > >>>> a identity > >>>> >> lookup via a database lookup service, and then use > the location > >>>> >> information received to help verify the caller's identity > >>>> presented > >>>> >> both via voice, as well as the external data > presented from the > >>>> >> identity database query. These external mechanisms are > >>>> >important for > >>>> >> many reasons, including helping callers who cannot, or will > >>>> >not speak, > >>>> >> to prevent false information from impeding > appropriate dispatch > >>>> >> instructions and procedures, and ultimately to enable faster > >>>> >response > >>>> >> in the offering of help." > >>>> >> > >>>> >> "IP-based emergency systems in the future may be able to > >>>> offer even > >>>> >> more information about the caller, to help establish personal > >>>> >> identity, but also for today, for near-term > >>>> implementations, need to > >>>> >> provide the same minimum level of identitifcation support > >>>> as in the > >>>> >> existing legacy emergency systems." > >>>> >> > >>>> >> "Req1: A "Call-back" number MUST be supplied within the call > >>>> >signaling > >>>> >> for each emergency call sent to the PSAP. The ECRIT > >protocol may > >>>> >> provide this number in the form of a tel:uri, a > sip:uri, or an > >>>> >> IP-Address." > >>>> >> > >>>> >> "Req2: The ECRIT protocol MUST support the ability for > >>>the PSAP to > >>>> >> perform caller identity lookup based on the tel:uri, > >>>> sip:uri, or IP > >>>> >> Address provided with call signaling. (A variety of > competing > >>>> >> directory lookup services may exist, but is not discussed > >>>> in detail > >>>> >> here, as it is out of scope of this document.)" > >>>> >> > >>>> >> "Req3: The ECRIT protocol MUST support the ability to > >associate > >>>> >> individual call location information with external caller > >>>identity > >>>> >> records." > >>>> >> > >>>> >> > >>>> >> > >>>> >> I have attempted to steer clear of obvious privacy > >>>> >> concerns/objections, modeling this after what's available > >>>> >today in ES, > >>>> >> but there are more details that some may want to tease out. > >>>> >> > >>>> >> Comments? > >>>> >> > >>>> >> Roger Marshall. > >>>> >> > >>>> >> _______________________________________________ > >>>> >> Ecrit mailing list > >>>> >> Ecrit@ietf.org > >>>> >> https://www1.ietf.org/mailman/listinfo/ecrit > >>>> >> > >>>> > > >>>> > >>> > >> > >>_______________________________________________ > >>Ecrit mailing list > >>Ecrit@ietf.org > >>https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 20 14:05:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESenF-0000Wz-NC; Thu, 20 Oct 2005 14:05:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESenC-0000Wu-Ug for ecrit@megatron.ietf.org; Thu, 20 Oct 2005 14:05:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04232 for ; Thu, 20 Oct 2005 14:05:20 -0400 (EDT) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESez9-00034g-Ti for ecrit@ietf.org; Thu, 20 Oct 2005 14:17:54 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1ESemt-0003FP-Hb; Thu, 20 Oct 2005 13:05:13 -0500 From: "Brian Rosen" To: "'Marc Linsner'" , "'Roger Marshall'" , "'Ted Hardie'" , "'Michael Hammer \(mhammer\)'" , "'ECRIT'" Subject: RE: [ECRIT]: Caller Identity requirements: replacement textforemptysection in ECRIT req doc. Date: Thu, 20 Oct 2005 14:01:47 -0400 Message-ID: <0a6301c5d5a0$5a1d9920$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXU//o3vfZgwnhCS9W1Yqc1f5/arQAk4H0AAAHC9TAAAWaA8A== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.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: 8cb9b411340046bf4080a729180a0672 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Ah, yes, there are actually two call backs. One is a URI that can be used to recreate the call if it is dropped for some reason. Another is a URI that should contact the caller at some later time. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner Sent: Thursday, October 20, 2005 1:34 PM To: 'Roger Marshall'; 'Ted Hardie'; 'Michael Hammer (mhammer)'; 'ECRIT' Subject: RE: [ECRIT]: Caller Identity requirements: replacement textforemptysection in ECRIT req doc. Sorry for not following this close enough. What is the definition of "call-back" in this context? Thanks, -Marc- > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Roger Marshall > Sent: Thursday, October 20, 2005 12:33 PM > To: Ted Hardie; Michael Hammer (mhammer); ECRIT > Subject: RE: [ECRIT]: Caller Identity requirements: > replacement text foremptysection in ECRIT req doc. > > Ted: > This is a good clarification, which (I think) meets all cases. > > Requirement is reworded as follows: > > Req-X. call-back uri. Req1: A "call-back" number MUST be > supplied within the call signaling for each emergency call > sent to the PSAP. The ECRIT protocol should provide this > number in the form of a URI appropriate to the method used to > contact the PSAP. > > Thanks. > > Roger Marshall. > > >-----Original Message----- > >From: Ted Hardie [mailto:hardie@qualcomm.com] > >Sent: Wednesday, October 19, 2005 3:53 PM > >To: Roger Marshall; Michael Hammer (mhammer); ECRIT > >Subject: RE: [ECRIT]: Caller Identity requirements: > >replacement text for emptysection in ECRIT req doc. > > > >At 10:56 AM -0700 10/19/05, Roger Marshall wrote: > >>Michael: > >>Henning suggests using SIP:URI alone. I like this, since > it makes it > >>avoids the issue of IP Address specifically, (and yet doesn't > >preclude > >>it, since I've written it as "should be in the form of a sip:uri". > > > >I would strongly prefer "in the form of a URI appropriate to > the method > >used to contact the PSAP". We've already seen cases where non-voice > >methods have been successful in reach emergency workers > where voice did > >not get through; if those were to use, say, an sms: URI then an sms: > >URI would be the appropriate contact for the reverse. > > > >A very recent U.S. example found here: > > > >http://www.nwanews.com/story.php?paper=adg§ion=News&story > id=133545 > > > > Ted > > > > > > > > > >>Given no objection, I've deleted my orig. req-2 (req-1 covers > >it), and > >>for 1 & 3, we now have: > >> > >>Req1. call-back uri. Req1: A "call-back" number MUST be supplied > >>within the call signaling for each emergency call sent to the PSAP. > >>The ECRIT protocol should provide this number in the form of > >a sip:uri. > >> > >>Req3. call identity parameters. The ECRIT protocol MUST > support the > >>transport of parameters which can be used by PSAPs to associate > >>individual call location information with external caller identity > >>records. > >> > >> > >>Roger Marshall. > >> > >>>-----Original Message----- > >>>From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > >>>Sent: Wednesday, October 19, 2005 10:36 AM > >>>To: Roger Marshall; ECRIT > >>>Subject: RE: [ECRIT]: Caller Identity requirements: > >>>replacement text for emptysection in ECRIT req doc. > >>> > >>>Yes, that helps. It could also be an IP address embedded in > >a sip URI > >>>in the form of a Contact, but I didn't want to presume too > much. I > >>>don't know if the call-back types need to be enumerated here > >or these > >>>are just used as examples. > >>> > >>>Mike > >>> > >>>> -----Original Message----- > >>>> From: Roger Marshall [mailto:RMarshall@telecomsys.com] > >>>> Sent: Wednesday, October 19, 2005 1:09 PM > >>>> To: Michael Hammer (mhammer); ECRIT > >>>> Subject: RE: [ECRIT]: Caller Identity requirements: > >>>> replacement text for emptysection in ECRIT req doc. > >>>> > >>>> Michael: > >>>> It seems that the PSAP needs to know which type of service > >>>> (application) that the caller could be used to contact the call > >>>> initiator. For example, if the ECRIT protocol provided an > >>>IP Address > >>>> as the "call-back" > >>>> number, the protocol SHOULD (or MUST?) provide an > indicator as to > >>>> which application is to be used to target this IP Address > >(e.g. IM, > >>>> email, VoIP, etc.). > >>>> > >>>> Does this get close to addressing the question you're asking? > >>>> > >>>> Roger Marshall. > >>>> > >>>> >-----Original Message----- > >>>> >From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > >>>> >Sent: Wednesday, October 19, 2005 8:43 AM > >>>> >To: Roger Marshall; ECRIT > >>>> >Subject: RE: [ECRIT]: Caller Identity requirements: > >>>> >replacement text for emptysection in ECRIT req doc. > >>>> > > >>>> >Roger, > >>>> > > >>>> >In Req-1, you mention an IP address as a call-back number. > >>>Is there > >>>> >some assumed higher level protocol that will be used > with that IP > >>>> >address? What will the PSAP operator do with it? > >>>> > > >>>> >Mike > >>>> > > >>>> >> -----Original Message----- > >>>> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >>>> >On Behalf > >>>> >> Of Roger Marshall > >>>> >> Sent: Tuesday, October 18, 2005 7:42 PM > >>>> >> To: ECRIT > >>>> >> Subject: [ECRIT]: Caller Identity requirements: > >>>> replacement text for > >>>> >> emptysection in ECRIT req doc. > >>>> >> > >>>> >> All: > >>>> >> There has been a placeholder within the ECRIT > >requirements draft > >>>> >> titled, "Emergency Caller Identification". Since this > >>>section was > >>>> >> requested back on 8/09, I guess I'll take a crack at > >>>> submitting some > >>>> >> (proposed) text for it (below): > >>>> >> > >>>> >> > >>>> >> "When a person places an emergency call to a PSAP, existing > >>>> >emergency > >>>> >> service messaging conveys associated caller information in > >> >> >addition to > >>>> >> receiving the caller's voice. > >>>> >> This additional information typically consists of a > >>>> >call-back number, > >>>> >> and the caller's location (referred to as ANI and ALI, > >for North > >>>> >> American systems)." > >>>> >> > >>>> >> "Some systems use the received callback number to perform > >>>> a identity > >>>> >> lookup via a database lookup service, and then use > the location > >>>> >> information received to help verify the caller's identity > >>>> presented > >>>> >> both via voice, as well as the external data > presented from the > >>>> >> identity database query. These external mechanisms are > >>>> >important for > >>>> >> many reasons, including helping callers who cannot, or will > >>>> >not speak, > >>>> >> to prevent false information from impeding > appropriate dispatch > >>>> >> instructions and procedures, and ultimately to enable faster > >>>> >response > >>>> >> in the offering of help." > >>>> >> > >>>> >> "IP-based emergency systems in the future may be able to > >>>> offer even > >>>> >> more information about the caller, to help establish personal > >>>> >> identity, but also for today, for near-term > >>>> implementations, need to > >>>> >> provide the same minimum level of identitifcation support > >>>> as in the > >>>> >> existing legacy emergency systems." > >>>> >> > >>>> >> "Req1: A "Call-back" number MUST be supplied within the call > >>>> >signaling > >>>> >> for each emergency call sent to the PSAP. The ECRIT > >protocol may > >>>> >> provide this number in the form of a tel:uri, a > sip:uri, or an > >>>> >> IP-Address." > >>>> >> > >>>> >> "Req2: The ECRIT protocol MUST support the ability for > >>>the PSAP to > >>>> >> perform caller identity lookup based on the tel:uri, > >>>> sip:uri, or IP > >>>> >> Address provided with call signaling. (A variety of > competing > >>>> >> directory lookup services may exist, but is not discussed > >>>> in detail > >>>> >> here, as it is out of scope of this document.)" > >>>> >> > >>>> >> "Req3: The ECRIT protocol MUST support the ability to > >associate > >>>> >> individual call location information with external caller > >>>identity > >>>> >> records." > >>>> >> > >>>> >> > >>>> >> > >>>> >> I have attempted to steer clear of obvious privacy > >>>> >> concerns/objections, modeling this after what's available > >>>> >today in ES, > >>>> >> but there are more details that some may want to tease out. > >>>> >> > >>>> >> Comments? > >>>> >> > >>>> >> Roger Marshall. > >>>> >> > >>>> >> _______________________________________________ > >>>> >> Ecrit mailing list > >>>> >> Ecrit@ietf.org > >>>> >> https://www1.ietf.org/mailman/listinfo/ecrit > >>>> >> > >>>> > > >>>> > >>> > >> > >>_______________________________________________ > >>Ecrit mailing list > >>Ecrit@ietf.org > >>https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 20 14:13:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESeud-0003q2-Au; Thu, 20 Oct 2005 14:13:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESeub-0003px-3z for ecrit@megatron.ietf.org; Thu, 20 Oct 2005 14:13:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04503 for ; Thu, 20 Oct 2005 14:12:59 -0400 (EDT) Received: from bay106-dav12.bay106.hotmail.com ([65.54.161.84] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESf6Z-0003Hf-HE for ecrit@ietf.org; Thu, 20 Oct 2005 14:25:32 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 20 Oct 2005 11:12:57 -0700 Message-ID: Received: from 12.178.162.5 by BAY106-DAV12.phx.gbl with DAV; Thu, 20 Oct 2005 18:12:56 +0000 X-Originating-IP: [12.178.162.5] X-Originating-Email: [timothydunn01@msn.com] X-Sender: timothydunn01@msn.com From: "Tim Dunn" To: "'Marc Linsner'" , "'Roger Marshall'" , "'Ted Hardie'" , "'Michael Hammer \(mhammer\)'" , "'ECRIT'" Subject: RE: [ECRIT]: Caller Identity requirements: replacement textforemptysection in ECRIT req doc. Date: Thu, 20 Oct 2005 12:12:54 -0600 Message-ID: <000f01c5d5a1$e495a330$1f071e0a@TimDunn> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXU//o3vfZgwnhCS9W1Yqc1f5/arQAk4H0AAAHC9TAAAbM9gA== In-Reply-To: AAAAAHid4H6cLVBKvI35MTImwgAHANlTnCJhprtFudq2LHCBs8EBACIA//8AANlTnCJhprtFudq2LHCBs8EBAHcrAAAAAA== X-OriginalArrivalTime: 20 Oct 2005 18:12:57.0767 (UTC) FILETIME=[E626A370:01C5D5A1] X-Spam-Score: 1.6 (+) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Marc- The definition from NENA Master Glossary (available at http://www.nena.org/9-1-1TechStandards/Standards_PDF/Master%20Glossary.pdf) and the way it is used in this context: Call Back - The capability to recontact the calling party Call Back Number - A number used by the PSAP to re-contact the location from which the 9-1-1 call was placed. The number may or may not be the number of the station used to originate the 9-1-1 call. Tim Dunn -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner Sent: Thursday, October 20, 2005 11:34 AM To: 'Roger Marshall'; 'Ted Hardie'; 'Michael Hammer (mhammer)'; 'ECRIT' Subject: RE: [ECRIT]: Caller Identity requirements: replacement textforemptysection in ECRIT req doc. Sorry for not following this close enough. What is the definition of "call-back" in this context? Thanks, -Marc- > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Roger Marshall > Sent: Thursday, October 20, 2005 12:33 PM > To: Ted Hardie; Michael Hammer (mhammer); ECRIT > Subject: RE: [ECRIT]: Caller Identity requirements: > replacement text foremptysection in ECRIT req doc. > > Ted: > This is a good clarification, which (I think) meets all cases. > > Requirement is reworded as follows: > > Req-X. call-back uri. Req1: A "call-back" number MUST be > supplied within the call signaling for each emergency call > sent to the PSAP. The ECRIT protocol should provide this > number in the form of a URI appropriate to the method used to > contact the PSAP. > > Thanks. > > Roger Marshall. > > >-----Original Message----- > >From: Ted Hardie [mailto:hardie@qualcomm.com] > >Sent: Wednesday, October 19, 2005 3:53 PM > >To: Roger Marshall; Michael Hammer (mhammer); ECRIT > >Subject: RE: [ECRIT]: Caller Identity requirements: > >replacement text for emptysection in ECRIT req doc. > > > >At 10:56 AM -0700 10/19/05, Roger Marshall wrote: > >>Michael: > >>Henning suggests using SIP:URI alone. I like this, since > it makes it > >>avoids the issue of IP Address specifically, (and yet doesn't > >preclude > >>it, since I've written it as "should be in the form of a sip:uri". > > > >I would strongly prefer "in the form of a URI appropriate to > the method > >used to contact the PSAP". We've already seen cases where non-voice > >methods have been successful in reach emergency workers > where voice did > >not get through; if those were to use, say, an sms: URI then an sms: > >URI would be the appropriate contact for the reverse. > > > >A very recent U.S. example found here: > > > >http://www.nwanews.com/story.php?paper=adg§ion=News&story > id=133545 > > > > Ted > > > > > > > > > >>Given no objection, I've deleted my orig. req-2 (req-1 covers > >it), and > >>for 1 & 3, we now have: > >> > >>Req1. call-back uri. Req1: A "call-back" number MUST be supplied > >>within the call signaling for each emergency call sent to the PSAP. > >>The ECRIT protocol should provide this number in the form of > >a sip:uri. > >> > >>Req3. call identity parameters. The ECRIT protocol MUST > support the > >>transport of parameters which can be used by PSAPs to associate > >>individual call location information with external caller identity > >>records. > >> > >> > >>Roger Marshall. > >> > >>>-----Original Message----- > >>>From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > >>>Sent: Wednesday, October 19, 2005 10:36 AM > >>>To: Roger Marshall; ECRIT > >>>Subject: RE: [ECRIT]: Caller Identity requirements: > >>>replacement text for emptysection in ECRIT req doc. > >>> > >>>Yes, that helps. It could also be an IP address embedded in > >a sip URI > >>>in the form of a Contact, but I didn't want to presume too > much. I > >>>don't know if the call-back types need to be enumerated here > >or these > >>>are just used as examples. > >>> > >>>Mike > >>> > >>>> -----Original Message----- > >>>> From: Roger Marshall [mailto:RMarshall@telecomsys.com] > >>>> Sent: Wednesday, October 19, 2005 1:09 PM > >>>> To: Michael Hammer (mhammer); ECRIT > >>>> Subject: RE: [ECRIT]: Caller Identity requirements: > >>>> replacement text for emptysection in ECRIT req doc. > >>>> > >>>> Michael: > >>>> It seems that the PSAP needs to know which type of service > >>>> (application) that the caller could be used to contact the call > >>>> initiator. For example, if the ECRIT protocol provided an > >>>IP Address > >>>> as the "call-back" > >>>> number, the protocol SHOULD (or MUST?) provide an > indicator as to > >>>> which application is to be used to target this IP Address > >(e.g. IM, > >>>> email, VoIP, etc.). > >>>> > >>>> Does this get close to addressing the question you're asking? > >>>> > >>>> Roger Marshall. > >>>> > >>>> >-----Original Message----- > >>>> >From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > >>>> >Sent: Wednesday, October 19, 2005 8:43 AM > >>>> >To: Roger Marshall; ECRIT > >>>> >Subject: RE: [ECRIT]: Caller Identity requirements: > >>>> >replacement text for emptysection in ECRIT req doc. > >>>> > > >>>> >Roger, > >>>> > > >>>> >In Req-1, you mention an IP address as a call-back number. > >>>Is there > >>>> >some assumed higher level protocol that will be used > with that IP > >>>> >address? What will the PSAP operator do with it? > >>>> > > >>>> >Mike > >>>> > > >>>> >> -----Original Message----- > >>>> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >>>> >On Behalf > >>>> >> Of Roger Marshall > >>>> >> Sent: Tuesday, October 18, 2005 7:42 PM > >>>> >> To: ECRIT > >>>> >> Subject: [ECRIT]: Caller Identity requirements: > >>>> replacement text for > >>>> >> emptysection in ECRIT req doc. > >>>> >> > >>>> >> All: > >>>> >> There has been a placeholder within the ECRIT > >requirements draft > >>>> >> titled, "Emergency Caller Identification". Since this > >>>section was > >>>> >> requested back on 8/09, I guess I'll take a crack at > >>>> submitting some > >>>> >> (proposed) text for it (below): > >>>> >> > >>>> >> > >>>> >> "When a person places an emergency call to a PSAP, existing > >>>> >emergency > >>>> >> service messaging conveys associated caller information in > >> >> >addition to > >>>> >> receiving the caller's voice. > >>>> >> This additional information typically consists of a > >>>> >call-back number, > >>>> >> and the caller's location (referred to as ANI and ALI, > >for North > >>>> >> American systems)." > >>>> >> > >>>> >> "Some systems use the received callback number to perform > >>>> a identity > >>>> >> lookup via a database lookup service, and then use > the location > >>>> >> information received to help verify the caller's identity > >>>> presented > >>>> >> both via voice, as well as the external data > presented from the > >>>> >> identity database query. These external mechanisms are > >>>> >important for > >>>> >> many reasons, including helping callers who cannot, or will > >>>> >not speak, > >>>> >> to prevent false information from impeding > appropriate dispatch > >>>> >> instructions and procedures, and ultimately to enable faster > >>>> >response > >>>> >> in the offering of help." > >>>> >> > >>>> >> "IP-based emergency systems in the future may be able to > >>>> offer even > >>>> >> more information about the caller, to help establish personal > >>>> >> identity, but also for today, for near-term > >>>> implementations, need to > >>>> >> provide the same minimum level of identitifcation support > >>>> as in the > >>>> >> existing legacy emergency systems." > >>>> >> > >>>> >> "Req1: A "Call-back" number MUST be supplied within the call > >>>> >signaling > >>>> >> for each emergency call sent to the PSAP. The ECRIT > >protocol may > >>>> >> provide this number in the form of a tel:uri, a > sip:uri, or an > >>>> >> IP-Address." > >>>> >> > >>>> >> "Req2: The ECRIT protocol MUST support the ability for > >>>the PSAP to > >>>> >> perform caller identity lookup based on the tel:uri, > >>>> sip:uri, or IP > >>>> >> Address provided with call signaling. (A variety of > competing > >>>> >> directory lookup services may exist, but is not discussed > >>>> in detail > >>>> >> here, as it is out of scope of this document.)" > >>>> >> > >>>> >> "Req3: The ECRIT protocol MUST support the ability to > >associate > >>>> >> individual call location information with external caller > >>>identity > >>>> >> records." > >>>> >> > >>>> >> > >>>> >> > >>>> >> I have attempted to steer clear of obvious privacy > >>>> >> concerns/objections, modeling this after what's available > >>>> >today in ES, > >>>> >> but there are more details that some may want to tease out. > >>>> >> > >>>> >> Comments? > >>>> >> > >>>> >> Roger Marshall. > >>>> >> > >>>> >> _______________________________________________ > >>>> >> Ecrit mailing list > >>>> >> Ecrit@ietf.org > >>>> >> https://www1.ietf.org/mailman/listinfo/ecrit > >>>> >> > >>>> > > >>>> > >>> > >> > >>_______________________________________________ > >>Ecrit mailing list > >>Ecrit@ietf.org > >>https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 20 14:25:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESf6E-0000VI-DC; Thu, 20 Oct 2005 14:25:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESf6C-0000SN-Jm for ecrit@megatron.ietf.org; Thu, 20 Oct 2005 14:25:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05023 for ; Thu, 20 Oct 2005 14:24:58 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESfIB-0003bv-Ej for ecrit@ietf.org; Thu, 20 Oct 2005 14:37:32 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 20 Oct 2005 11:24:58 -0700 X-IronPort-AV: i="3.97,236,1125903600"; d="scan'208"; a="354694060:sNHT964623732" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9KIOT9S028260; Thu, 20 Oct 2005 11:24:55 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 11:24:54 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 11:24:53 -0700 From: "Marc Linsner" To: , "'Roger Marshall'" , "'Ted Hardie'" , "'Michael Hammer \(mhammer\)'" , "'ECRIT'" Subject: RE: [ECRIT]: Caller Identity requirements: replacement textforemptysection in ECRIT req doc. Date: Thu, 20 Oct 2005 14:24:44 -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: AcXU//o3vfZgwnhCS9W1Yqc1f5/arQAk4H0AAAHC9TAAAWaA8AAAtu4g In-Reply-To: <0a6301c5d5a0$5a1d9920$640fa8c0@cis.neustar.com> Message-ID: X-OriginalArrivalTime: 20 Oct 2005 18:24:53.0729 (UTC) FILETIME=[90E5C510:01C5D5A3] X-Spam-Score: 1.1 (+) X-Scan-Signature: 4515df9441674711565101d9d5c4f63f Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This begs the question..... "Req1: A "call-back" number MUST be supplied within the call signaling for each emergency call sent to the PSAP. The ECRIT protocol should provide this number in the form of a URI appropriate to the method used to contact the PSAP." Why is ECRIT responsible for "call-back"? -Marc- > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, October 20, 2005 2:02 PM > To: 'Marc Linsner'; 'Roger Marshall'; 'Ted Hardie'; 'Michael > Hammer (mhammer)'; 'ECRIT' > Subject: RE: [ECRIT]: Caller Identity requirements: > replacement textforemptysection in ECRIT req doc. > > Ah, yes, there are actually two call backs. > > One is a URI that can be used to recreate the call if it is > dropped for some reason. > > Another is a URI that should contact the caller at some later time. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Marc Linsner > Sent: Thursday, October 20, 2005 1:34 PM > To: 'Roger Marshall'; 'Ted Hardie'; 'Michael Hammer > (mhammer)'; 'ECRIT' > Subject: RE: [ECRIT]: Caller Identity requirements: > replacement textforemptysection in ECRIT req doc. > > Sorry for not following this close enough. > > What is the definition of "call-back" in this context? > > Thanks, > > -Marc- > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Roger Marshall > > Sent: Thursday, October 20, 2005 12:33 PM > > To: Ted Hardie; Michael Hammer (mhammer); ECRIT > > Subject: RE: [ECRIT]: Caller Identity requirements: > > replacement text foremptysection in ECRIT req doc. > > > > Ted: > > This is a good clarification, which (I think) meets all cases. > > > > Requirement is reworded as follows: > > > > Req-X. call-back uri. Req1: A "call-back" number MUST be supplied > > within the call signaling for each emergency call sent to > the PSAP. > > The ECRIT protocol should provide this number in the form of a URI > > appropriate to the method used to contact the PSAP. > > > > Thanks. > > > > Roger Marshall. > > > > >-----Original Message----- > > >From: Ted Hardie [mailto:hardie@qualcomm.com] > > >Sent: Wednesday, October 19, 2005 3:53 PM > > >To: Roger Marshall; Michael Hammer (mhammer); ECRIT > > >Subject: RE: [ECRIT]: Caller Identity requirements: > > >replacement text for emptysection in ECRIT req doc. > > > > > >At 10:56 AM -0700 10/19/05, Roger Marshall wrote: > > >>Michael: > > >>Henning suggests using SIP:URI alone. I like this, since > > it makes it > > >>avoids the issue of IP Address specifically, (and yet doesn't > > >preclude > > >>it, since I've written it as "should be in the form of a sip:uri". > > > > > >I would strongly prefer "in the form of a URI appropriate to > > the method > > >used to contact the PSAP". We've already seen cases where > non-voice > > >methods have been successful in reach emergency workers > > where voice did > > >not get through; if those were to use, say, an sms: URI > then an sms: > > >URI would be the appropriate contact for the reverse. > > > > > >A very recent U.S. example found here: > > > > > >http://www.nwanews.com/story.php?paper=adg§ion=News&story > > id=133545 > > > > > > Ted > > > > > > > > > > > > > > >>Given no objection, I've deleted my orig. req-2 (req-1 covers > > >it), and > > >>for 1 & 3, we now have: > > >> > > >>Req1. call-back uri. Req1: A "call-back" number MUST be supplied > > >>within the call signaling for each emergency call sent to > the PSAP. > > >>The ECRIT protocol should provide this number in the form of > > >a sip:uri. > > >> > > >>Req3. call identity parameters. The ECRIT protocol MUST > > support the > > >>transport of parameters which can be used by PSAPs to associate > > >>individual call location information with external caller > identity > > >>records. > > >> > > >> > > >>Roger Marshall. > > >> > > >>>-----Original Message----- > > >>>From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > >>>Sent: Wednesday, October 19, 2005 10:36 AM > > >>>To: Roger Marshall; ECRIT > > >>>Subject: RE: [ECRIT]: Caller Identity requirements: > > >>>replacement text for emptysection in ECRIT req doc. > > >>> > > >>>Yes, that helps. It could also be an IP address embedded in > > >a sip URI > > >>>in the form of a Contact, but I didn't want to presume too > > much. I > > >>>don't know if the call-back types need to be enumerated here > > >or these > > >>>are just used as examples. > > >>> > > >>>Mike > > >>> > > >>>> -----Original Message----- > > >>>> From: Roger Marshall [mailto:RMarshall@telecomsys.com] > > >>>> Sent: Wednesday, October 19, 2005 1:09 PM > > >>>> To: Michael Hammer (mhammer); ECRIT > > >>>> Subject: RE: [ECRIT]: Caller Identity requirements: > > >>>> replacement text for emptysection in ECRIT req doc. > > >>>> > > >>>> Michael: > > >>>> It seems that the PSAP needs to know which type of service > > >>>> (application) that the caller could be used to contact > the call > > >>>> initiator. For example, if the ECRIT protocol provided an > > >>>IP Address > > >>>> as the "call-back" > > >>>> number, the protocol SHOULD (or MUST?) provide an > > indicator as to > > >>>> which application is to be used to target this IP Address > > >(e.g. IM, > > >>>> email, VoIP, etc.). > > >>>> > > >>>> Does this get close to addressing the question you're asking? > > >>>> > > >>>> Roger Marshall. > > >>>> > > >>>> >-----Original Message----- > > >>>> >From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > >>>> >Sent: Wednesday, October 19, 2005 8:43 AM > > >>>> >To: Roger Marshall; ECRIT > > >>>> >Subject: RE: [ECRIT]: Caller Identity requirements: > > >>>> >replacement text for emptysection in ECRIT req doc. > > >>>> > > > >>>> >Roger, > > >>>> > > > >>>> >In Req-1, you mention an IP address as a call-back number. > > >>>Is there > > >>>> >some assumed higher level protocol that will be used > > with that IP > > >>>> >address? What will the PSAP operator do with it? > > >>>> > > > >>>> >Mike > > >>>> > > > >>>> >> -----Original Message----- > > >>>> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > >>>> >On Behalf > > >>>> >> Of Roger Marshall > > >>>> >> Sent: Tuesday, October 18, 2005 7:42 PM > > >>>> >> To: ECRIT > > >>>> >> Subject: [ECRIT]: Caller Identity requirements: > > >>>> replacement text for > > >>>> >> emptysection in ECRIT req doc. > > >>>> >> > > >>>> >> All: > > >>>> >> There has been a placeholder within the ECRIT > > >requirements draft > > >>>> >> titled, "Emergency Caller Identification". Since this > > >>>section was > > >>>> >> requested back on 8/09, I guess I'll take a crack at > > >>>> submitting some > > >>>> >> (proposed) text for it (below): > > >>>> >> > > >>>> >> > > >>>> >> "When a person places an emergency call to a PSAP, existing > > >>>> >emergency > > >>>> >> service messaging conveys associated caller information in > > >> >> >addition to > > >>>> >> receiving the caller's voice. > > >>>> >> This additional information typically consists of a > > >>>> >call-back number, > > >>>> >> and the caller's location (referred to as ANI and ALI, > > >for North > > >>>> >> American systems)." > > >>>> >> > > >>>> >> "Some systems use the received callback number to perform > > >>>> a identity > > >>>> >> lookup via a database lookup service, and then use > > the location > > >>>> >> information received to help verify the caller's identity > > >>>> presented > > >>>> >> both via voice, as well as the external data > > presented from the > > >>>> >> identity database query. These external mechanisms are > > >>>> >important for > > >>>> >> many reasons, including helping callers who cannot, or will > > >>>> >not speak, > > >>>> >> to prevent false information from impeding > > appropriate dispatch > > >>>> >> instructions and procedures, and ultimately to enable faster > > >>>> >response > > >>>> >> in the offering of help." > > >>>> >> > > >>>> >> "IP-based emergency systems in the future may be able to > > >>>> offer even > > >>>> >> more information about the caller, to help > establish personal > > >>>> >> identity, but also for today, for near-term > > >>>> implementations, need to > > >>>> >> provide the same minimum level of identitifcation support > > >>>> as in the > > >>>> >> existing legacy emergency systems." > > >>>> >> > > >>>> >> "Req1: A "Call-back" number MUST be supplied within the call > > >>>> >signaling > > >>>> >> for each emergency call sent to the PSAP. The ECRIT > > >protocol may > > >>>> >> provide this number in the form of a tel:uri, a > > sip:uri, or an > > >>>> >> IP-Address." > > >>>> >> > > >>>> >> "Req2: The ECRIT protocol MUST support the ability for > > >>>the PSAP to > > >>>> >> perform caller identity lookup based on the tel:uri, > > >>>> sip:uri, or IP > > >>>> >> Address provided with call signaling. (A variety of > > competing > > >>>> >> directory lookup services may exist, but is not discussed > > >>>> in detail > > >>>> >> here, as it is out of scope of this document.)" > > >>>> >> > > >>>> >> "Req3: The ECRIT protocol MUST support the ability to > > >associate > > >>>> >> individual call location information with external caller > > >>>identity > > >>>> >> records." > > >>>> >> > > >>>> >> > > >>>> >> > > >>>> >> I have attempted to steer clear of obvious privacy > > >>>> >> concerns/objections, modeling this after what's available > > >>>> >today in ES, > > >>>> >> but there are more details that some may want to tease out. > > >>>> >> > > >>>> >> Comments? > > >>>> >> > > >>>> >> Roger Marshall. > > >>>> >> > > >>>> >> _______________________________________________ > > >>>> >> Ecrit mailing list > > >>>> >> Ecrit@ietf.org > > >>>> >> https://www1.ietf.org/mailman/listinfo/ecrit > > >>>> >> > > >>>> > > > >>>> > > >>> > > >> > > >>_______________________________________________ > > >>Ecrit mailing list > > >>Ecrit@ietf.org > > >>https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 20 14:49:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESfTS-0001Ea-Kd; Thu, 20 Oct 2005 14:49:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESfTQ-0001EP-W9 for ecrit@megatron.ietf.org; Thu, 20 Oct 2005 14:49:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06168 for ; Thu, 20 Oct 2005 14:48:58 -0400 (EDT) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESffQ-0004Ii-8S for ecrit@ietf.org; Thu, 20 Oct 2005 15:01:32 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1ESfTF-0004pu-8J; Thu, 20 Oct 2005 13:48:57 -0500 From: "Brian Rosen" To: "'Marc Linsner'" , "'Roger Marshall'" , "'Ted Hardie'" , "'Michael Hammer \(mhammer\)'" , "'ECRIT'" Subject: RE: [ECRIT]: Caller Identity requirements: replacement textforemptysection in ECRIT req doc. Date: Thu, 20 Oct 2005 14:45:02 -0400 Message-ID: <0a7201c5d5a6$63624840$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXU//o3vfZgwnhCS9W1Yqc1f5/arQAk4H0AAAHC9TAAAWaA8AAAtu4gAADSy0A= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.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: b360bd6cb019c35178e5cf9eeb747a5c Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org If not ecrit (which I'll accept), then which work group do we take this requirement. Brian -----Original Message----- From: Marc Linsner [mailto:mlinsner@cisco.com] Sent: Thursday, October 20, 2005 2:25 PM To: br@brianrosen.net; 'Roger Marshall'; 'Ted Hardie'; 'Michael Hammer (mhammer)'; 'ECRIT' Subject: RE: [ECRIT]: Caller Identity requirements: replacement textforemptysection in ECRIT req doc. This begs the question..... "Req1: A "call-back" number MUST be supplied within the call signaling for each emergency call sent to the PSAP. The ECRIT protocol should provide this number in the form of a URI appropriate to the method used to contact the PSAP." Why is ECRIT responsible for "call-back"? -Marc- > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, October 20, 2005 2:02 PM > To: 'Marc Linsner'; 'Roger Marshall'; 'Ted Hardie'; 'Michael > Hammer (mhammer)'; 'ECRIT' > Subject: RE: [ECRIT]: Caller Identity requirements: > replacement textforemptysection in ECRIT req doc. > > Ah, yes, there are actually two call backs. > > One is a URI that can be used to recreate the call if it is > dropped for some reason. > > Another is a URI that should contact the caller at some later time. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Marc Linsner > Sent: Thursday, October 20, 2005 1:34 PM > To: 'Roger Marshall'; 'Ted Hardie'; 'Michael Hammer > (mhammer)'; 'ECRIT' > Subject: RE: [ECRIT]: Caller Identity requirements: > replacement textforemptysection in ECRIT req doc. > > Sorry for not following this close enough. > > What is the definition of "call-back" in this context? > > Thanks, > > -Marc- > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Roger Marshall > > Sent: Thursday, October 20, 2005 12:33 PM > > To: Ted Hardie; Michael Hammer (mhammer); ECRIT > > Subject: RE: [ECRIT]: Caller Identity requirements: > > replacement text foremptysection in ECRIT req doc. > > > > Ted: > > This is a good clarification, which (I think) meets all cases. > > > > Requirement is reworded as follows: > > > > Req-X. call-back uri. Req1: A "call-back" number MUST be supplied > > within the call signaling for each emergency call sent to > the PSAP. > > The ECRIT protocol should provide this number in the form of a URI > > appropriate to the method used to contact the PSAP. > > > > Thanks. > > > > Roger Marshall. > > > > >-----Original Message----- > > >From: Ted Hardie [mailto:hardie@qualcomm.com] > > >Sent: Wednesday, October 19, 2005 3:53 PM > > >To: Roger Marshall; Michael Hammer (mhammer); ECRIT > > >Subject: RE: [ECRIT]: Caller Identity requirements: > > >replacement text for emptysection in ECRIT req doc. > > > > > >At 10:56 AM -0700 10/19/05, Roger Marshall wrote: > > >>Michael: > > >>Henning suggests using SIP:URI alone. I like this, since > > it makes it > > >>avoids the issue of IP Address specifically, (and yet doesn't > > >preclude > > >>it, since I've written it as "should be in the form of a sip:uri". > > > > > >I would strongly prefer "in the form of a URI appropriate to > > the method > > >used to contact the PSAP". We've already seen cases where > non-voice > > >methods have been successful in reach emergency workers > > where voice did > > >not get through; if those were to use, say, an sms: URI > then an sms: > > >URI would be the appropriate contact for the reverse. > > > > > >A very recent U.S. example found here: > > > > > >http://www.nwanews.com/story.php?paper=adg§ion=News&story > > id=133545 > > > > > > Ted > > > > > > > > > > > > > > >>Given no objection, I've deleted my orig. req-2 (req-1 covers > > >it), and > > >>for 1 & 3, we now have: > > >> > > >>Req1. call-back uri. Req1: A "call-back" number MUST be supplied > > >>within the call signaling for each emergency call sent to > the PSAP. > > >>The ECRIT protocol should provide this number in the form of > > >a sip:uri. > > >> > > >>Req3. call identity parameters. The ECRIT protocol MUST > > support the > > >>transport of parameters which can be used by PSAPs to associate > > >>individual call location information with external caller > identity > > >>records. > > >> > > >> > > >>Roger Marshall. > > >> > > >>>-----Original Message----- > > >>>From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > >>>Sent: Wednesday, October 19, 2005 10:36 AM > > >>>To: Roger Marshall; ECRIT > > >>>Subject: RE: [ECRIT]: Caller Identity requirements: > > >>>replacement text for emptysection in ECRIT req doc. > > >>> > > >>>Yes, that helps. It could also be an IP address embedded in > > >a sip URI > > >>>in the form of a Contact, but I didn't want to presume too > > much. I > > >>>don't know if the call-back types need to be enumerated here > > >or these > > >>>are just used as examples. > > >>> > > >>>Mike > > >>> > > >>>> -----Original Message----- > > >>>> From: Roger Marshall [mailto:RMarshall@telecomsys.com] > > >>>> Sent: Wednesday, October 19, 2005 1:09 PM > > >>>> To: Michael Hammer (mhammer); ECRIT > > >>>> Subject: RE: [ECRIT]: Caller Identity requirements: > > >>>> replacement text for emptysection in ECRIT req doc. > > >>>> > > >>>> Michael: > > >>>> It seems that the PSAP needs to know which type of service > > >>>> (application) that the caller could be used to contact > the call > > >>>> initiator. For example, if the ECRIT protocol provided an > > >>>IP Address > > >>>> as the "call-back" > > >>>> number, the protocol SHOULD (or MUST?) provide an > > indicator as to > > >>>> which application is to be used to target this IP Address > > >(e.g. IM, > > >>>> email, VoIP, etc.). > > >>>> > > >>>> Does this get close to addressing the question you're asking? > > >>>> > > >>>> Roger Marshall. > > >>>> > > >>>> >-----Original Message----- > > >>>> >From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > >>>> >Sent: Wednesday, October 19, 2005 8:43 AM > > >>>> >To: Roger Marshall; ECRIT > > >>>> >Subject: RE: [ECRIT]: Caller Identity requirements: > > >>>> >replacement text for emptysection in ECRIT req doc. > > >>>> > > > >>>> >Roger, > > >>>> > > > >>>> >In Req-1, you mention an IP address as a call-back number. > > >>>Is there > > >>>> >some assumed higher level protocol that will be used > > with that IP > > >>>> >address? What will the PSAP operator do with it? > > >>>> > > > >>>> >Mike > > >>>> > > > >>>> >> -----Original Message----- > > >>>> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > >>>> >On Behalf > > >>>> >> Of Roger Marshall > > >>>> >> Sent: Tuesday, October 18, 2005 7:42 PM > > >>>> >> To: ECRIT > > >>>> >> Subject: [ECRIT]: Caller Identity requirements: > > >>>> replacement text for > > >>>> >> emptysection in ECRIT req doc. > > >>>> >> > > >>>> >> All: > > >>>> >> There has been a placeholder within the ECRIT > > >requirements draft > > >>>> >> titled, "Emergency Caller Identification". Since this > > >>>section was > > >>>> >> requested back on 8/09, I guess I'll take a crack at > > >>>> submitting some > > >>>> >> (proposed) text for it (below): > > >>>> >> > > >>>> >> > > >>>> >> "When a person places an emergency call to a PSAP, existing > > >>>> >emergency > > >>>> >> service messaging conveys associated caller information in > > >> >> >addition to > > >>>> >> receiving the caller's voice. > > >>>> >> This additional information typically consists of a > > >>>> >call-back number, > > >>>> >> and the caller's location (referred to as ANI and ALI, > > >for North > > >>>> >> American systems)." > > >>>> >> > > >>>> >> "Some systems use the received callback number to perform > > >>>> a identity > > >>>> >> lookup via a database lookup service, and then use > > the location > > >>>> >> information received to help verify the caller's identity > > >>>> presented > > >>>> >> both via voice, as well as the external data > > presented from the > > >>>> >> identity database query. These external mechanisms are > > >>>> >important for > > >>>> >> many reasons, including helping callers who cannot, or will > > >>>> >not speak, > > >>>> >> to prevent false information from impeding > > appropriate dispatch > > >>>> >> instructions and procedures, and ultimately to enable faster > > >>>> >response > > >>>> >> in the offering of help." > > >>>> >> > > >>>> >> "IP-based emergency systems in the future may be able to > > >>>> offer even > > >>>> >> more information about the caller, to help > establish personal > > >>>> >> identity, but also for today, for near-term > > >>>> implementations, need to > > >>>> >> provide the same minimum level of identitifcation support > > >>>> as in the > > >>>> >> existing legacy emergency systems." > > >>>> >> > > >>>> >> "Req1: A "Call-back" number MUST be supplied within the call > > >>>> >signaling > > >>>> >> for each emergency call sent to the PSAP. The ECRIT > > >protocol may > > >>>> >> provide this number in the form of a tel:uri, a > > sip:uri, or an > > >>>> >> IP-Address." > > >>>> >> > > >>>> >> "Req2: The ECRIT protocol MUST support the ability for > > >>>the PSAP to > > >>>> >> perform caller identity lookup based on the tel:uri, > > >>>> sip:uri, or IP > > >>>> >> Address provided with call signaling. (A variety of > > competing > > >>>> >> directory lookup services may exist, but is not discussed > > >>>> in detail > > >>>> >> here, as it is out of scope of this document.)" > > >>>> >> > > >>>> >> "Req3: The ECRIT protocol MUST support the ability to > > >associate > > >>>> >> individual call location information with external caller > > >>>identity > > >>>> >> records." > > >>>> >> > > >>>> >> > > >>>> >> > > >>>> >> I have attempted to steer clear of obvious privacy > > >>>> >> concerns/objections, modeling this after what's available > > >>>> >today in ES, > > >>>> >> but there are more details that some may want to tease out. > > >>>> >> > > >>>> >> Comments? > > >>>> >> > > >>>> >> Roger Marshall. > > >>>> >> > > >>>> >> _______________________________________________ > > >>>> >> Ecrit mailing list > > >>>> >> Ecrit@ietf.org > > >>>> >> https://www1.ietf.org/mailman/listinfo/ecrit > > >>>> >> > > >>>> > > > >>>> > > >>> > > >> > > >>_______________________________________________ > > >>Ecrit mailing list > > >>Ecrit@ietf.org > > >>https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 20 15:28:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESg5H-0001JY-As; Thu, 20 Oct 2005 15:28:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESg5G-0001JT-DA for ecrit@megatron.ietf.org; Thu, 20 Oct 2005 15:28:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08631 for ; Thu, 20 Oct 2005 15:28:04 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESgHE-0005a6-Ui for ecrit@ietf.org; Thu, 20 Oct 2005 15:40:38 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 20 Oct 2005 15:28:03 -0400 X-IronPort-AV: i="3.97,236,1125892800"; d="scan'208,217"; a="74109263:sNHT43688324" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9KJRo2D017654; Thu, 20 Oct 2005 15:28:01 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 15:27:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00 -Security and Reliability Date: Thu, 20 Oct 2005 15:27:51 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3AE657E@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00 -Security and Reliability Thread-Index: AcXUFgkgLdjmuMKwRiGnpzSRU7iXYQBcwEYgAAjJHjA= From: "Michael Hammer \(mhammer\)" To: , X-OriginalArrivalTime: 20 Oct 2005 19:27:52.0587 (UTC) FILETIME=[5D45BDB0:01C5D5AC] X-Spam-Score: 0.7 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0503741739==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0503741739== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D5AC.5D1F6011" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D5AC.5D1F6011 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Brian, =20 Routing information is rather broad and could be interpreted to mean an SP can not manage its own proxy routing capabilities. Could you make this more specific to what you had in mind. =20 Mike =20 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Thursday, October 20, 2005 11:16 AM To: ecrit@ietf.org Subject: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00 -Security and Reliability =09 =09 More comments from NENA:=20 Our requirement 3.6-16: Information and mechanisms used to determine routing must be extremely reliable and available, which implies redundancy, protocol stability, and resiliency is not adequately addressed by I8. Resilience against server failure: A client MUST be able to fail over to another replica of the mapping server, so that a failure of a server does not endanger the ability to perform the mapping. We also don't think this adequately addresses 3.8-1: There shall be no single point of failure or 3.8-3: Special consideration should be given to distributed Denial of Service of Service attacks. We recognize this is part of the security issues being covered in another document. =20 We do not find something that covers our requirement 3.6-17: Routing information must be secured against unauthorized modification. PSAPs (or perhaps a higher level civic authority such as a county, state/province or national body) or their designated representative must be the only entities permitted to change routing information. =20 ------_=_NextPart_001_01C5D5AC.5D1F6011 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Brian,
 
Routing information is rather broad and could be = interpreted to=20 mean an SP can not manage its own proxy routing capabilities.  = Could you=20 make this more specific to what you had in mind.
 
Mike
 

From: ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian=20 Rosen
Sent: Thursday, October 20, 2005 11:16 = AM
To:=20 ecrit@ietf.org
Subject: [Ecrit] NENA Comments on=20 draft-ietf-ecrit-requirements-00 -Security and=20 Reliability

More <delayed> comments from = NENA:=20

Our requirement 3.6-16: Information and = mechanisms=20 used to determine routing must be extremely reliable and available, = which=20 implies redundancy, protocol stability, and resiliency is not = adequately=20 addressed by I8.  Resilience against server failure: A client = MUST be=20 able to fail over to another replica of the mapping server, so that a = failure=20 of a server does not endanger the ability to perform the = mapping.  We=20 also don’t think this adequately addresses 3.8-1: There shall be = no single=20 point of failure or 3.8-3: Special consideration should be given to=20 distributed Denial of Service of Service attacks.  We recognize = this is=20 part of the security issues being covered in another=20 document.

 

We do not find something that covers our = requirement=20 3.6-17: Routing information must be secured against unauthorized=20 modification.  PSAPs (or perhaps a higher level civic authority = such as a=20 county, state/province or national body) or their designated = representative=20 must be the only entities permitted to change routing=20 information.

 

------_=_NextPart_001_01C5D5AC.5D1F6011-- --===============0503741739== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0503741739==-- From ecrit-bounces@ietf.org Thu Oct 20 15:43:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESgJc-0007Iu-Cw; Thu, 20 Oct 2005 15:43:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESgJb-0007IV-3J for ecrit@megatron.ietf.org; Thu, 20 Oct 2005 15:43:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09446 for ; Thu, 20 Oct 2005 15:42:52 -0400 (EDT) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESgVb-00063x-2f for ecrit@ietf.org; Thu, 20 Oct 2005 15:55:27 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1ESgJQ-0006x8-4R; Thu, 20 Oct 2005 14:42:52 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , Subject: RE: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00 -Security and Reliability Date: Thu, 20 Oct 2005 15:39:07 -0400 Message-ID: <0a8101c5d5ad$f287c610$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3AE657E@xmb-rtp-20b.amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXUFgkgLdjmuMKwRiGnpzSRU7iXYQBcwEYgAAjJHjAAAGVeAA== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.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.3 (/) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1077636765==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1077636765== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A82_01C5D58C.6B762610" This is a multi-part message in MIME format. ------=_NextPart_000_0A82_01C5D58C.6B762610 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In this context, we are talking about the mapping information. Using mapping information would distinguish our issue from your concern, would it not? Brian _____ From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Thursday, October 20, 2005 3:28 PM To: br@brianrosen.net; ecrit@ietf.org Subject: RE: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00 -Security and Reliability Brian, Routing information is rather broad and could be interpreted to mean an SP can not manage its own proxy routing capabilities. Could you make this more specific to what you had in mind. Mike _____ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Thursday, October 20, 2005 11:16 AM To: ecrit@ietf.org Subject: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00 -Security and Reliability More comments from NENA: Our requirement 3.6-16: Information and mechanisms used to determine routing must be extremely reliable and available, which implies redundancy, protocol stability, and resiliency is not adequately addressed by I8. Resilience against server failure: A client MUST be able to fail over to another replica of the mapping server, so that a failure of a server does not endanger the ability to perform the mapping. We also don't think this adequately addresses 3.8-1: There shall be no single point of failure or 3.8-3: Special consideration should be given to distributed Denial of Service of Service attacks. We recognize this is part of the security issues being covered in another document. We do not find something that covers our requirement 3.6-17: Routing information must be secured against unauthorized modification. PSAPs (or perhaps a higher level civic authority such as a county, state/province or national body) or their designated representative must be the only entities permitted to change routing information. ------=_NextPart_000_0A82_01C5D58C.6B762610 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

In this context, we are talking = about the mapping information.  Using mapping information would distinguish = our issue from your concern, would it not?

 

Brian

 

From: = Michael Hammer (mhammer) [mailto:mhammer@cisco.com]
Sent: Thursday, October = 20, 2005 3:28 PM
To: br@brianrosen.net; ecrit@ietf.org
Subject: RE: [Ecrit] NENA = Comments on draft-ietf-ecrit-requirements-00 -Security and = Reliability

 

Brian,

 

Routing information is rather = broad and could be interpreted to mean an SP can not manage its own proxy routing capabilities.  Could you make this more specific to what you had in = mind.

 

Mike

 

=

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen
Sent: Thursday, October = 20, 2005 11:16 AM
To: ecrit@ietf.org
Subject: [Ecrit] NENA = Comments on draft-ietf-ecrit-requirements-00 -Security and = Reliability

More <delayed> comments from NENA:

Our requirement 3.6-16: Information and mechanisms used to = determine routing must be extremely reliable and available, which implies = redundancy, protocol stability, and resiliency is not adequately addressed by = I8.  Resilience against server failure: A client MUST be able to fail over to another replica of the mapping server, so that a failure of a server = does not endanger the ability to perform the mapping.  We also don’t = think this adequately addresses 3.8-1: There shall be no single point of = failure or 3.8-3: Special consideration should be given to distributed Denial of = Service of Service attacks.  We recognize this is part of the security = issues being covered in another document.

 

We do not find something that covers our requirement 3.6-17: = Routing information must be secured against unauthorized modification.  = PSAPs (or perhaps a higher level civic authority such as a county, state/province = or national body) or their designated representative must be the only = entities permitted to change routing information.

 

------=_NextPart_000_0A82_01C5D58C.6B762610-- --===============1077636765== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1077636765==-- From ecrit-bounces@ietf.org Thu Oct 20 15:47:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESgNe-0000Qv-71; Thu, 20 Oct 2005 15:47:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESgNc-0000Qn-N3 for ecrit@megatron.ietf.org; Thu, 20 Oct 2005 15:47:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09734 for ; Thu, 20 Oct 2005 15:47:01 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESgZb-0006F9-9s for ecrit@ietf.org; Thu, 20 Oct 2005 15:59:36 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1ESgNa-00061I-Cj for ecrit@ietf.org; Thu, 20 Oct 2005 15:47:10 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 20 Oct 2005 12:45:37 -0700 X-IronPort-AV: i="3.97,236,1125903600"; d="scan'208"; a="354734047:sNHT26448914" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9KJivKF022963; Thu, 20 Oct 2005 12:45:34 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 12:45:26 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 12:45:23 -0700 From: "Marc Linsner" To: Subject: RE: [ECRIT]: Caller Identity requirements: replacement text for emptysection in ECRIT req doc. Date: Thu, 20 Oct 2005 15:45:15 -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: AcXT3Y4AM/FQSqnNRaiWsmbORCxXIgAWwzzAAF0v0MA= In-Reply-To: <8C837214C95C864C9F34F3635C2A6575035F6367@SEA-EXCHVS-2.telecomsys.com> Message-ID: X-OriginalArrivalTime: 20 Oct 2005 19:45:25.0869 (UTC) FILETIME=[D113D1D0:01C5D5AE] X-Spam-Score: 1.1 (+) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org OK, I believe I have found the source of the "call-back' thread (with a little bumping from Roger). Brian, After looking over ecrit's charter again, I can't find where ecrit needs to worry about caller identity. I sympothize with your requirement, but I just can't find a place for it in ecrit. Does anybody have a different opinion?? Caller Identity going once, going twice,......... -Marc- > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Roger Marshall > Sent: Tuesday, October 18, 2005 7:42 PM > To: ECRIT > Subject: [ECRIT]: Caller Identity requirements: replacement > text for emptysection in ECRIT req doc. > > All: > There has been a placeholder within the ECRIT requirements > draft titled, "Emergency Caller Identification". Since this > section was requested back on 8/09, I guess I'll take a crack > at submitting some (proposed) text for it (below): > > > "When a person places an emergency call to a PSAP, existing > emergency service messaging conveys associated caller > information in addition to receiving the caller's voice. > This additional information typically consists of a call-back > number, and the caller's location (referred to as ANI and > ALI, for North American systems)." > > "Some systems use the received callback number to perform a > identity lookup via a database lookup service, and then use > the location information received to help verify the caller's > identity presented both via voice, as well as the external > data presented from the identity database query. These > external mechanisms are important for many reasons, including > helping callers who cannot, or will not speak, to prevent > false information from impeding appropriate dispatch > instructions and procedures, and ultimately to enable faster > response in the offering of help." > > "IP-based emergency systems in the future may be able to > offer even more information about the caller, to help > establish personal identity, but also for today, for > near-term implementations, need to provide the same minimum > level of identitifcation support as in the existing legacy > emergency systems." > > "Req1: A "Call-back" number MUST be supplied within the call > signaling for each emergency call sent to the PSAP. The > ECRIT protocol may provide this number in the form of a > tel:uri, a sip:uri, or an IP-Address." > > "Req2: The ECRIT protocol MUST support the ability for the > PSAP to perform caller identity lookup based on the tel:uri, > sip:uri, or IP Address provided with call signaling. (A > variety of competing directory lookup services may exist, but > is not discussed in detail here, as it is out of scope of > this document.)" > > "Req3: The ECRIT protocol MUST support the ability to > associate individual call location information with external > caller identity records." > > > > I have attempted to steer clear of obvious privacy > concerns/objections, modeling this after what's available > today in ES, but there are more details that some may want to > tease out. > > Comments? > > Roger Marshall. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 20 15:48:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESgOh-0000f1-N4; Thu, 20 Oct 2005 15:48:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESgOe-0000eL-HT for ecrit@megatron.ietf.org; Thu, 20 Oct 2005 15:48:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09778 for ; Thu, 20 Oct 2005 15:48:06 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESgae-0006Gc-Dj for ecrit@ietf.org; Thu, 20 Oct 2005 16:00:41 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 20 Oct 2005 15:48:07 -0400 X-IronPort-AV: i="3.97,236,1125892800"; d="scan'208,217"; a="74110967:sNHT46280284" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9KJlkF0002817; Thu, 20 Oct 2005 15:48:05 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 15:48:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00 -Security and Reliability Date: Thu, 20 Oct 2005 15:48:03 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3AE659E@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00 -Security and Reliability Thread-Index: AcXUFgkgLdjmuMKwRiGnpzSRU7iXYQBcwEYgAAjJHjAAAGVeAAAAQe2g From: "Michael Hammer \(mhammer\)" To: , X-OriginalArrivalTime: 20 Oct 2005 19:48:04.0673 (UTC) FILETIME=[2FBB6310:01C5D5AF] X-Spam-Score: 0.4 (/) X-Scan-Signature: a630332fa112280ecc4c4186b5c9ea83 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2106910085==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============2106910085== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D5AF.2F8F0D1F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D5AF.2F8F0D1F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe it will so long as the particular mapping information is spelled out. You are referring to location to PSAP URI mapping? =20 Mike =20 ________________________________ From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Thursday, October 20, 2005 3:39 PM To: Michael Hammer (mhammer); ecrit@ietf.org Subject: RE: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00 -Security and Reliability =09 =09 In this context, we are talking about the mapping information. Using mapping information would distinguish our issue from your concern, would it not? =20 Brian =20 =09 ________________________________ From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 Sent: Thursday, October 20, 2005 3:28 PM To: br@brianrosen.net; ecrit@ietf.org Subject: RE: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00 -Security and Reliability =20 Brian, =20 Routing information is rather broad and could be interpreted to mean an SP can not manage its own proxy routing capabilities. Could you make this more specific to what you had in mind. =20 Mike =20 =20 =09 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Thursday, October 20, 2005 11:16 AM To: ecrit@ietf.org Subject: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00 -Security and Reliability More comments from NENA:=20 Our requirement 3.6-16: Information and mechanisms used to determine routing must be extremely reliable and available, which implies redundancy, protocol stability, and resiliency is not adequately addressed by I8. Resilience against server failure: A client MUST be able to fail over to another replica of the mapping server, so that a failure of a server does not endanger the ability to perform the mapping. We also don't think this adequately addresses 3.8-1: There shall be no single point of failure or 3.8-3: Special consideration should be given to distributed Denial of Service of Service attacks. We recognize this is part of the security issues being covered in another document. =20 We do not find something that covers our requirement 3.6-17: Routing information must be secured against unauthorized modification. PSAPs (or perhaps a higher level civic authority such as a county, state/province or national body) or their designated representative must be the only entities permitted to change routing information. =20 ------_=_NextPart_001_01C5D5AF.2F8F0D1F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I believe it will so long as the particular mapping = information is=20 spelled out.
You are referring to location to PSAP URI=20 mapping?
 
Mike
 

From: Brian Rosen = [mailto:br@brianrosen.net]=20
Sent: Thursday, October 20, 2005 3:39 PM
To: = Michael=20 Hammer (mhammer); ecrit@ietf.org
Subject: RE: [Ecrit] NENA = Comments=20 on draft-ietf-ecrit-requirements-00 -Security and=20 Reliability

In this = context, we=20 are talking about the mapping information.  Using mapping = information=20 would distinguish our issue from your concern, would it=20 not?

 

Brian

 

From: Michael=20 Hammer (mhammer) [mailto:mhammer@cisco.com]
Sent: Thursday, October 20, = 2005 3:28=20 PM
To: = br@brianrosen.net; = ecrit@ietf.org
Subject: RE: [Ecrit] NENA = Comments on=20 draft-ietf-ecrit-requirements-00 -Security and=20 Reliability

 

Brian,

 

Routing = information=20 is rather broad and could be interpreted to mean an SP can not manage = its own=20 proxy routing capabilities.  Could you make this more specific to = what=20 you had in mind.

 

Mike

 

 

From:=20 ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian = Rosen
Sent: Thursday, October 20, = 2005 11:16=20 AM
To:=20 ecrit@ietf.org
Subject:=20 [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00 -Security = and=20 Reliability

More <delayed> comments from = NENA:=20

Our requirement 3.6-16: Information and = mechanisms=20 used to determine routing must be extremely reliable and available, = which=20 implies redundancy, protocol stability, and resiliency is not = adequately=20 addressed by I8.  Resilience against server failure: A client = MUST be=20 able to fail over to another replica of the mapping server, so that = a=20 failure of a server does not endanger the ability to perform the=20 mapping.  We also don’t think this adequately addresses = 3.8-1: There=20 shall be no single point of failure or 3.8-3: Special consideration = should=20 be given to distributed Denial of Service of Service attacks.  = We=20 recognize this is part of the security issues being covered in = another=20 document.

 

We do not find something that covers our = requirement=20 3.6-17: Routing information must be secured against unauthorized=20 modification.  PSAPs (or perhaps a higher level civic authority = such as=20 a county, state/province or national body) or their designated=20 representative must be the only entities permitted to change routing = information.

 

------_=_NextPart_001_01C5D5AF.2F8F0D1F-- --===============2106910085== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============2106910085==-- From ecrit-bounces@ietf.org Thu Oct 20 16:15:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESgom-0005BH-DE; Thu, 20 Oct 2005 16:15:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESgoj-00058g-RM for ecrit@megatron.ietf.org; Thu, 20 Oct 2005 16:15:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17899 for ; Thu, 20 Oct 2005 16:15:02 -0400 (EDT) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESh0h-00019X-4X for ecrit@ietf.org; Thu, 20 Oct 2005 16:27:37 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1ESgoU-0008Aw-Ie; Thu, 20 Oct 2005 15:14:59 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , Subject: RE: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00 -Security and Reliability Date: Thu, 20 Oct 2005 16:10:45 -0400 Message-ID: <0b0601c5d5b2$5cbca8d0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3AE659E@xmb-rtp-20b.amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXUFgkgLdjmuMKwRiGnpzSRU7iXYQBcwEYgAAjJHjAAAGVeAAAAQe2gAADgIdA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.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.2 (/) X-Scan-Signature: 69ad46fbd0e474a7c7f3312d9e320336 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1120136641==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1120136641== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0B07_01C5D590.D5AB08D0" This is a multi-part message in MIME format. ------=_NextPart_000_0B07_01C5D590.D5AB08D0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit yes _____ From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Thursday, October 20, 2005 3:48 PM To: br@brianrosen.net; ecrit@ietf.org Subject: RE: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00 -Security and Reliability I believe it will so long as the particular mapping information is spelled out. You are referring to location to PSAP URI mapping? Mike _____ From: Brian Rosen [mailto:br@brianrosen.net] Sent: Thursday, October 20, 2005 3:39 PM To: Michael Hammer (mhammer); ecrit@ietf.org Subject: RE: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00 -Security and Reliability In this context, we are talking about the mapping information. Using mapping information would distinguish our issue from your concern, would it not? Brian _____ From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Thursday, October 20, 2005 3:28 PM To: br@brianrosen.net; ecrit@ietf.org Subject: RE: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00 -Security and Reliability Brian, Routing information is rather broad and could be interpreted to mean an SP can not manage its own proxy routing capabilities. Could you make this more specific to what you had in mind. Mike _____ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Thursday, October 20, 2005 11:16 AM To: ecrit@ietf.org Subject: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00 -Security and Reliability More comments from NENA: Our requirement 3.6-16: Information and mechanisms used to determine routing must be extremely reliable and available, which implies redundancy, protocol stability, and resiliency is not adequately addressed by I8. Resilience against server failure: A client MUST be able to fail over to another replica of the mapping server, so that a failure of a server does not endanger the ability to perform the mapping. We also don't think this adequately addresses 3.8-1: There shall be no single point of failure or 3.8-3: Special consideration should be given to distributed Denial of Service of Service attacks. We recognize this is part of the security issues being covered in another document. We do not find something that covers our requirement 3.6-17: Routing information must be secured against unauthorized modification. PSAPs (or perhaps a higher level civic authority such as a county, state/province or national body) or their designated representative must be the only entities permitted to change routing information. ------=_NextPart_000_0B07_01C5D590.D5AB08D0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

yes

 

From: = Michael Hammer (mhammer) [mailto:mhammer@cisco.com]
Sent: Thursday, October = 20, 2005 3:48 PM
To: br@brianrosen.net; ecrit@ietf.org
Subject: RE: [Ecrit] NENA = Comments on draft-ietf-ecrit-requirements-00 -Security and = Reliability

 

I believe it will so long as the particular mapping information is spelled = out.

You are referring to location to = PSAP URI mapping?

 

Mike

 

=

 

From: Brian Rosen [mailto:br@brianrosen.net]
Sent: Thursday, October = 20, 2005 3:39 PM
To: Michael Hammer = (mhammer); ecrit@ietf.org
Subject: RE: [Ecrit] NENA = Comments on draft-ietf-ecrit-requirements-00 -Security and = Reliability

In this context, we are talking = about the mapping information.  Using mapping information would distinguish = our issue from your concern, would it not?

 

Brian

 

From: = Michael Hammer (mhammer) [mailto:mhammer@cisco.com]
Sent: Thursday, October = 20, 2005 3:28 PM
To: br@brianrosen.net; ecrit@ietf.org
Subject: RE: [Ecrit] NENA = Comments on draft-ietf-ecrit-requirements-00 -Security and = Reliability

 

Brian,

 

Routing information is rather = broad and could be interpreted to mean an SP can not manage its own proxy routing capabilities.  Could you make this more specific to what you had in = mind.

 

Mike

 

=

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen
Sent: Thursday, October = 20, 2005 11:16 AM
To: ecrit@ietf.org
Subject: [Ecrit] NENA = Comments on draft-ietf-ecrit-requirements-00 -Security and = Reliability

More <delayed> comments from NENA:

Our requirement 3.6-16: Information and mechanisms used to = determine routing must be extremely reliable and available, which implies = redundancy, protocol stability, and resiliency is not adequately addressed by = I8.  Resilience against server failure: A client MUST be able to fail over to another replica of the mapping server, so that a failure of a server = does not endanger the ability to perform the mapping.  We also don’t = think this adequately addresses 3.8-1: There shall be no single point of = failure or 3.8-3: Special consideration should be given to distributed Denial of = Service of Service attacks.  We recognize this is part of the security = issues being covered in another document.

 

We do not find something that covers our requirement 3.6-17: = Routing information must be secured against unauthorized modification.  = PSAPs (or perhaps a higher level civic authority such as a county, state/province = or national body) or their designated representative must be the only = entities permitted to change routing information.

 

------=_NextPart_000_0B07_01C5D590.D5AB08D0-- --===============1120136641== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1120136641==-- From ecrit-bounces@ietf.org Thu Oct 20 16:20:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESgtO-0000sf-N9; Thu, 20 Oct 2005 16:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESgtN-0000s4-CE for ecrit@megatron.ietf.org; Thu, 20 Oct 2005 16:20:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20760 for ; Thu, 20 Oct 2005 16:19:50 -0400 (EDT) Received: from bay106-dav8.bay106.hotmail.com ([65.54.161.80] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESh5L-0002DE-0r for ecrit@ietf.org; Thu, 20 Oct 2005 16:32:25 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 20 Oct 2005 13:19:19 -0700 Message-ID: Received: from 12.178.162.5 by BAY106-DAV8.phx.gbl with DAV; Thu, 20 Oct 2005 20:19:18 +0000 X-Originating-IP: [12.178.162.5] X-Originating-Email: [timothydunn01@msn.com] X-Sender: timothydunn01@msn.com From: "Tim Dunn" To: "'Marc Linsner'" , Subject: RE: [ECRIT]: Caller Identity requirements: replacement text foremptysection in ECRIT req doc. Date: Thu, 20 Oct 2005 14:19:16 -0600 Message-ID: <003301c5d5b3$8c20cfb0$1f071e0a@TimDunn> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXT3Y4AM/FQSqnNRaiWsmbORCxXIgAWwzzAAF0v0MAAAPYhgA== In-Reply-To: AAAAAHid4H6cLVBKvI35MTImwgAHANlTnCJhprtFudq2LHCBs8EBACIA//8AANlTnCJhprtFudq2LHCBs8EBAIwrAAAAAA== X-OriginalArrivalTime: 20 Oct 2005 20:19:19.0130 (UTC) FILETIME=[8CFED3A0:01C5D5B3] X-Spam-Score: 1.6 (+) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: 7bit Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I'm assuming the charter is at: http://www.ietf.org/html.charters/ecrit-charter.html A very limited view read of the charter is: "Internet technologies available to describe location and to manage call routing." The only item explicitly out of scope is: "... the question of pre-emption or prioritization of emergency services traffic." I would argue that the tying the location of the caller to a way to re-contact that caller (especially if the call disconnects and the caller cannot be located) is a part of the native existing processes of "...special call centers equipped to manage emergency response." The charter does say "While this group anticipates a close working relationship with groups such as NENA and ETSI EMTEL, any solution presented must be useful regardless of jurisdiction..." I'll argue that NENA, ETSI EMTEL or any jurisdiction that manages a "special call center" would want to know why there's no standardized method to provide a call back number associated with a caller's location. What you are proposing by eliminating a call back number is a solution that could be considered out of scope because it is not useful. Tim Dunn -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner Sent: Thursday, October 20, 2005 1:45 PM To: br@brianrosen.net Cc: 'ECRIT' Subject: RE: [ECRIT]: Caller Identity requirements: replacement text foremptysection in ECRIT req doc. OK, I believe I have found the source of the "call-back' thread (with a little bumping from Roger). Brian, After looking over ecrit's charter again, I can't find where ecrit needs to worry about caller identity. I sympothize with your requirement, but I just can't find a place for it in ecrit. Does anybody have a different opinion?? Caller Identity going once, going twice,......... -Marc- > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Roger Marshall > Sent: Tuesday, October 18, 2005 7:42 PM > To: ECRIT > Subject: [ECRIT]: Caller Identity requirements: replacement > text for emptysection in ECRIT req doc. > > All: > There has been a placeholder within the ECRIT requirements > draft titled, "Emergency Caller Identification". Since this > section was requested back on 8/09, I guess I'll take a crack > at submitting some (proposed) text for it (below): > > > "When a person places an emergency call to a PSAP, existing > emergency service messaging conveys associated caller > information in addition to receiving the caller's voice. > This additional information typically consists of a call-back > number, and the caller's location (referred to as ANI and > ALI, for North American systems)." > > "Some systems use the received callback number to perform a > identity lookup via a database lookup service, and then use > the location information received to help verify the caller's > identity presented both via voice, as well as the external > data presented from the identity database query. These > external mechanisms are important for many reasons, including > helping callers who cannot, or will not speak, to prevent > false information from impeding appropriate dispatch > instructions and procedures, and ultimately to enable faster > response in the offering of help." > > "IP-based emergency systems in the future may be able to > offer even more information about the caller, to help > establish personal identity, but also for today, for > near-term implementations, need to provide the same minimum > level of identitifcation support as in the existing legacy > emergency systems." > > "Req1: A "Call-back" number MUST be supplied within the call > signaling for each emergency call sent to the PSAP. The > ECRIT protocol may provide this number in the form of a > tel:uri, a sip:uri, or an IP-Address." > > "Req2: The ECRIT protocol MUST support the ability for the > PSAP to perform caller identity lookup based on the tel:uri, > sip:uri, or IP Address provided with call signaling. (A > variety of competing directory lookup services may exist, but > is not discussed in detail here, as it is out of scope of > this document.)" > > "Req3: The ECRIT protocol MUST support the ability to > associate individual call location information with external > caller identity records." > > > > I have attempted to steer clear of obvious privacy > concerns/objections, modeling this after what's available > today in ES, but there are more details that some may want to > tease out. > > Comments? > > Roger Marshall. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 20 17:32:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESi1Z-0005w6-GO; Thu, 20 Oct 2005 17:32:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESi08-00045A-0i for ecrit@megatron.ietf.org; Thu, 20 Oct 2005 17:31:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04957 for ; Thu, 20 Oct 2005 17:12:57 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EShny-0005HE-S1 for ecrit@ietf.org; Thu, 20 Oct 2005 17:18:33 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 20 Oct 2005 14:05:54 -0700 X-IronPort-AV: i="3.97,237,1125903600"; d="scan'208"; a="354775357:sNHT27553628" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9KL5f9E026786; Thu, 20 Oct 2005 14:05:53 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 14:05:51 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 14:05:51 -0700 From: "Marc Linsner" To: "'Tim Dunn'" , Subject: RE: [ECRIT]: Caller Identity requirements: replacement text foremptysection in ECRIT req doc. Date: Thu, 20 Oct 2005 17:05:42 -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: AcXT3Y4AM/FQSqnNRaiWsmbORCxXIgAWwzzAAF0v0MAAAPYhgAABEgjw In-Reply-To: Message-ID: X-OriginalArrivalTime: 20 Oct 2005 21:05:51.0276 (UTC) FILETIME=[0D3E7EC0:01C5D5BA] X-Spam-Score: 2.2 (++) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Content-Transfer-Encoding: 7bit Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Tim, I'm not saying that "call-back" is not a requirement. I'm stating that it is not a requirement that ECRIT must solve. I agree that Caller Identity requirement(s) are necessary for proper emergency calling operations. ECRIT is narrowly chartered and I interpret ECRIT's charter as 2 things: 1) Identify an emergency call. 2) Given location information, resolve to a PSAP URI. There will be a future document from ECRIT that outlines various emergency calling requirements that ECRIT did not/will not handle. I suspect Caller Identity requirement should be in that document. -Marc- > -----Original Message----- > From: Tim Dunn [mailto:timothydunn01@msn.com] > Sent: Thursday, October 20, 2005 4:19 PM > To: 'Marc Linsner'; br@brianrosen.net > Cc: 'ECRIT' > Subject: RE: [ECRIT]: Caller Identity requirements: > replacement text foremptysection in ECRIT req doc. > > I'm assuming the charter is at: > http://www.ietf.org/html.charters/ecrit-charter.html > > A very limited view read of the charter is: > > "Internet technologies available to describe location and to > manage call routing." > > The only item explicitly out of scope is: > > "... the question of pre-emption or prioritization of > emergency services traffic." > > I would argue that the tying the location of the caller to a > way to re-contact that caller (especially if the call > disconnects and the caller cannot be located) is a part of > the native existing processes of "...special call centers > equipped to manage emergency response." > > The charter does say "While this group anticipates a close > working relationship with groups such as NENA and ETSI EMTEL, > any solution presented must be useful regardless of > jurisdiction..." I'll argue that NENA, ETSI EMTEL or any > jurisdiction that manages a "special call center" would want > to know why there's no standardized method to provide a call > back number associated with a caller's location. What you > are proposing by eliminating a call back number is a solution > that could be considered out of scope because it is not useful. > > Tim Dunn > > > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Marc Linsner > Sent: Thursday, October 20, 2005 1:45 PM > To: br@brianrosen.net > Cc: 'ECRIT' > Subject: RE: [ECRIT]: Caller Identity requirements: > replacement text foremptysection in ECRIT req doc. > > OK, I believe I have found the source of the "call-back' > thread (with a little bumping from Roger). > > Brian, > > After looking over ecrit's charter again, I can't find where > ecrit needs to worry about caller identity. I sympothize > with your requirement, but I just can't find a place for it in ecrit. > > Does anybody have a different opinion?? > > Caller Identity going once, going twice,......... > > -Marc- > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Roger Marshall > > Sent: Tuesday, October 18, 2005 7:42 PM > > To: ECRIT > > Subject: [ECRIT]: Caller Identity requirements: replacement > text for > > emptysection in ECRIT req doc. > > > > All: > > There has been a placeholder within the ECRIT requirements draft > > titled, "Emergency Caller Identification". Since this section was > > requested back on 8/09, I guess I'll take a crack at > submitting some > > (proposed) text for it (below): > > > > > > "When a person places an emergency call to a PSAP, existing > emergency > > service messaging conveys associated caller information in > addition to > > receiving the caller's voice. > > This additional information typically consists of a > call-back number, > > and the caller's location (referred to as ANI and ALI, for North > > American systems)." > > > > "Some systems use the received callback number to perform a > identity > > lookup via a database lookup service, and then use the location > > information received to help verify the caller's identity presented > > both via voice, as well as the external data presented from the > > identity database query. These external mechanisms are > important for > > many reasons, including helping callers who cannot, or will > not speak, > > to prevent false information from impeding appropriate dispatch > > instructions and procedures, and ultimately to enable > faster response > > in the offering of help." > > > > "IP-based emergency systems in the future may be able to offer even > > more information about the caller, to help establish personal > > identity, but also for today, for near-term > implementations, need to > > provide the same minimum level of identitifcation support as in the > > existing legacy emergency systems." > > > > "Req1: A "Call-back" number MUST be supplied within the > call signaling > > for each emergency call sent to the PSAP. The ECRIT protocol may > > provide this number in the form of a tel:uri, a sip:uri, or an > > IP-Address." > > > > "Req2: The ECRIT protocol MUST support the ability for the PSAP to > > perform caller identity lookup based on the tel:uri, sip:uri, or IP > > Address provided with call signaling. (A variety of competing > > directory lookup services may exist, but is not discussed in detail > > here, as it is out of scope of this document.)" > > > > "Req3: The ECRIT protocol MUST support the ability to associate > > individual call location information with external caller identity > > records." > > > > > > > > I have attempted to steer clear of obvious privacy > > concerns/objections, modeling this after what's available > today in ES, > > but there are more details that some may want to tease out. > > > > Comments? > > > > Roger Marshall. > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 20 17:59:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESiRs-0001Jx-CX; Thu, 20 Oct 2005 17:59:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESiRp-0001II-16 for ecrit@megatron.ietf.org; Thu, 20 Oct 2005 17:59:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16197 for ; Thu, 20 Oct 2005 17:59:30 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESiWB-0000ec-PV for ecrit@ietf.org; Thu, 20 Oct 2005 18:04:12 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Thu, 20 Oct 2005 17:51:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ECRIT]: Caller Identity requirements: replacement textforemptysection in ECRIT req doc. Date: Thu, 20 Oct 2005 14:51:27 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65750364594B@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [ECRIT]: Caller Identity requirements: replacement textforemptysection in ECRIT req doc. Thread-Index: AcXT3Y4AM/FQSqnNRaiWsmbORCxXIgAWwzzAAF0v0MAAAPYhgAABEgjwAAJ0swA= From: "Roger Marshall" To: "Marc Linsner" , "Tim Dunn" , X-Spam-Score: 1.1 (+) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Content-Transfer-Encoding: quoted-printable Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Given the charter language (as I read it), it does seem that focusing on a mechanism for a PSAP to exercise call-back may be out scope for this set of goals. I plan to reserve this section on call-back for another (future) draft. Roger Marshall.=20 Editor >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Marc Linsner >Sent: Thursday, October 20, 2005 2:06 PM >To: 'Tim Dunn'; br@brianrosen.net >Cc: 'ECRIT' >Subject: RE: [ECRIT]: Caller Identity requirements:=20 >replacement textforemptysection in ECRIT req doc. > >Tim, > >I'm not saying that "call-back" is not a requirement. I'm=20 >stating that it is not a requirement that ECRIT must solve. I=20 >agree that Caller Identity >requirement(s) are necessary for proper emergency calling operations. > >ECRIT is narrowly chartered and I interpret ECRIT's charter as=20 >2 things: > >1) Identify an emergency call. > >2) Given location information, resolve to a PSAP URI. > >There will be a future document from ECRIT that outlines=20 >various emergency calling requirements that ECRIT did not/will=20 >not handle. I suspect Caller Identity requirement should be=20 >in that document. > >-Marc- > >> -----Original Message----- >> From: Tim Dunn [mailto:timothydunn01@msn.com] >> Sent: Thursday, October 20, 2005 4:19 PM >> To: 'Marc Linsner'; br@brianrosen.net >> Cc: 'ECRIT' >> Subject: RE: [ECRIT]: Caller Identity requirements:=20 >> replacement text foremptysection in ECRIT req doc. >>=20 >> I'm assuming the charter is at: >> http://www.ietf.org/html.charters/ecrit-charter.html >>=20 >> A very limited view read of the charter is: >>=20 >> "Internet technologies available to describe location and to manage=20 >> call routing." >>=20 >> The only item explicitly out of scope is: >>=20 >> "... the question of pre-emption or prioritization of emergency=20 >> services traffic." >>=20 >> I would argue that the tying the location of the caller to a way to=20 >> re-contact that caller (especially if the call disconnects and the=20 >> caller cannot be located) is a part of the native existing processes=20 >> of "...special call centers equipped to manage emergency response." >>=20 >> The charter does say "While this group anticipates a close working=20 >> relationship with groups such as NENA and ETSI EMTEL, any solution=20 >> presented must be useful regardless of jurisdiction..." I'll argue=20 >> that NENA, ETSI EMTEL or any jurisdiction that manages a=20 >"special call=20 >> center" would want to know why there's no standardized method to=20 >> provide a call back number associated with a caller's=20 >location. What=20 >> you are proposing by eliminating a call back number is a=20 >solution that=20 >> could be considered out of scope because it is not useful. >>=20 >> Tim Dunn >>=20 >>=20 >>=20 >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf=20 >> Of Marc Linsner >> Sent: Thursday, October 20, 2005 1:45 PM >> To: br@brianrosen.net >> Cc: 'ECRIT' >> Subject: RE: [ECRIT]: Caller Identity requirements:=20 >> replacement text foremptysection in ECRIT req doc.=20 >>=20 >> OK, I believe I have found the source of the "call-back'=20 >> thread (with a little bumping from Roger). >>=20 >> Brian, >>=20 >> After looking over ecrit's charter again, I can't find where ecrit=20 >> needs to worry about caller identity. I sympothize with your=20 >> requirement, but I just can't find a place for it in ecrit. >>=20 >> Does anybody have a different opinion?? >>=20 >> Caller Identity going once, going twice,......... >>=20 >> -Marc- >>=20 >> > -----Original Message----- >> > From: ecrit-bounces@ietf.org >> [mailto:ecrit-bounces@ietf.org] On Behalf >> > Of Roger Marshall >> > Sent: Tuesday, October 18, 2005 7:42 PM >> > To: ECRIT >> > Subject: [ECRIT]: Caller Identity requirements: replacement >> text for >> > emptysection in ECRIT req doc. >> >=20 >> > All: >> > There has been a placeholder within the ECRIT requirements draft=20 >> > titled, "Emergency Caller Identification". Since this section was=20 >> > requested back on 8/09, I guess I'll take a crack at >> submitting some >> > (proposed) text for it (below): >> >=20 >> >=20 >> > "When a person places an emergency call to a PSAP, existing >> emergency >> > service messaging conveys associated caller information in >> addition to >> > receiving the caller's voice. >> > This additional information typically consists of a >> call-back number, >> > and the caller's location (referred to as ANI and ALI, for North=20 >> > American systems)." >> >=20 >> > "Some systems use the received callback number to perform a >> identity >> > lookup via a database lookup service, and then use the location=20 >> > information received to help verify the caller's identity=20 >presented=20 >> > both via voice, as well as the external data presented from the=20 >> > identity database query. These external mechanisms are >> important for >> > many reasons, including helping callers who cannot, or will >> not speak, >> > to prevent false information from impeding appropriate dispatch=20 >> > instructions and procedures, and ultimately to enable >> faster response >> > in the offering of help." >> >=20 >> > "IP-based emergency systems in the future may be able to=20 >offer even=20 >> > more information about the caller, to help establish personal=20 >> > identity, but also for today, for near-term >> implementations, need to >> > provide the same minimum level of identitifcation support=20 >as in the=20 >> > existing legacy emergency systems." >> >=20 >> > "Req1: A "Call-back" number MUST be supplied within the >> call signaling >> > for each emergency call sent to the PSAP. The ECRIT protocol may=20 >> > provide this number in the form of a tel:uri, a sip:uri, or an=20 >> > IP-Address." >> >=20 >> > "Req2: The ECRIT protocol MUST support the ability for the PSAP to=20 >> > perform caller identity lookup based on the tel:uri,=20 >sip:uri, or IP=20 >> > Address provided with call signaling. (A variety of competing=20 >> > directory lookup services may exist, but is not discussed=20 >in detail=20 >> > here, as it is out of scope of this document.)" >> >=20 >> > "Req3: The ECRIT protocol MUST support the ability to associate=20 >> > individual call location information with external caller identity=20 >> > records." >> >=20 >> >=20 >> >=20 >> > I have attempted to steer clear of obvious privacy=20 >> > concerns/objections, modeling this after what's available >> today in ES, >> > but there are more details that some may want to tease out. >> >=20 >> > Comments? >> >=20 >> > Roger Marshall. >> >=20 >> > _______________________________________________ >> > Ecrit mailing list >> > Ecrit@ietf.org >> > https://www1.ietf.org/mailman/listinfo/ecrit >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 20 17:59:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESiRv-0001MO-O8; Thu, 20 Oct 2005 17:59:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESiRu-0001Ld-Ce for ecrit@megatron.ietf.org; Thu, 20 Oct 2005 17:59:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16257 for ; Thu, 20 Oct 2005 17:59:35 -0400 (EDT) Received: from bay106-dav5.bay106.hotmail.com ([65.54.161.77] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESiTu-0000GJ-Nl for ecrit@ietf.org; Thu, 20 Oct 2005 18:01:52 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 20 Oct 2005 14:49:15 -0700 Message-ID: Received: from 12.178.162.5 by BAY106-DAV5.phx.gbl with DAV; Thu, 20 Oct 2005 21:49:14 +0000 X-Originating-IP: [12.178.162.5] X-Originating-Email: [timothydunn01@msn.com] X-Sender: timothydunn01@msn.com From: "Tim Dunn" To: "'Marc Linsner'" , Subject: RE: [ECRIT]: Caller Identity requirements: replacement text foremptysection in ECRIT req doc. Date: Thu, 20 Oct 2005 15:49:12 -0600 Message-ID: <007b01c5d5c0$1c3a0a10$1f071e0a@TimDunn> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXT3Y4AM/FQSqnNRaiWsmbORCxXIgAWwzzAAF0v0MAAAPYhgAABEgjwAAJ+qeA= In-Reply-To: AAAAAHid4H6cLVBKvI35MTImwgAHANlTnCJhprtFudq2LHCBs8EBACIA//8AANlTnCJhprtFudq2LHCBs8EBAJQrAAAAAA== X-OriginalArrivalTime: 20 Oct 2005 21:49:15.0764 (UTC) FILETIME=[1DA3D340:01C5D5C0] X-Spam-Score: 2.7 (++) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Content-Transfer-Encoding: 7bit Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Marc- I'll express this in terms of ECRIT scope. A caller's location is made up of 2 things: Physical location on the ground and their identity at that physical location (i.e. callback). What the PSAP does with the callback, I'll agree, is out of scope. But as a part of the basic location identity of the caller, it's location and callback. Tim -----Original Message----- From: Marc Linsner [mailto:mlinsner@cisco.com] Sent: Thursday, October 20, 2005 3:06 PM To: 'Tim Dunn'; br@brianrosen.net Cc: 'ECRIT' Subject: RE: [ECRIT]: Caller Identity requirements: replacement text foremptysection in ECRIT req doc. Tim, I'm not saying that "call-back" is not a requirement. I'm stating that it is not a requirement that ECRIT must solve. I agree that Caller Identity requirement(s) are necessary for proper emergency calling operations. ECRIT is narrowly chartered and I interpret ECRIT's charter as 2 things: 1) Identify an emergency call. 2) Given location information, resolve to a PSAP URI. There will be a future document from ECRIT that outlines various emergency calling requirements that ECRIT did not/will not handle. I suspect Caller Identity requirement should be in that document. -Marc- > -----Original Message----- > From: Tim Dunn [mailto:timothydunn01@msn.com] > Sent: Thursday, October 20, 2005 4:19 PM > To: 'Marc Linsner'; br@brianrosen.net > Cc: 'ECRIT' > Subject: RE: [ECRIT]: Caller Identity requirements: > replacement text foremptysection in ECRIT req doc. > > I'm assuming the charter is at: > http://www.ietf.org/html.charters/ecrit-charter.html > > A very limited view read of the charter is: > > "Internet technologies available to describe location and to > manage call routing." > > The only item explicitly out of scope is: > > "... the question of pre-emption or prioritization of > emergency services traffic." > > I would argue that the tying the location of the caller to a > way to re-contact that caller (especially if the call > disconnects and the caller cannot be located) is a part of > the native existing processes of "...special call centers > equipped to manage emergency response." > > The charter does say "While this group anticipates a close > working relationship with groups such as NENA and ETSI EMTEL, > any solution presented must be useful regardless of > jurisdiction..." I'll argue that NENA, ETSI EMTEL or any > jurisdiction that manages a "special call center" would want > to know why there's no standardized method to provide a call > back number associated with a caller's location. What you > are proposing by eliminating a call back number is a solution > that could be considered out of scope because it is not useful. > > Tim Dunn > > > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Marc Linsner > Sent: Thursday, October 20, 2005 1:45 PM > To: br@brianrosen.net > Cc: 'ECRIT' > Subject: RE: [ECRIT]: Caller Identity requirements: > replacement text foremptysection in ECRIT req doc. > > OK, I believe I have found the source of the "call-back' > thread (with a little bumping from Roger). > > Brian, > > After looking over ecrit's charter again, I can't find where > ecrit needs to worry about caller identity. I sympothize > with your requirement, but I just can't find a place for it in ecrit. > > Does anybody have a different opinion?? > > Caller Identity going once, going twice,......... > > -Marc- > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Roger Marshall > > Sent: Tuesday, October 18, 2005 7:42 PM > > To: ECRIT > > Subject: [ECRIT]: Caller Identity requirements: replacement > text for > > emptysection in ECRIT req doc. > > > > All: > > There has been a placeholder within the ECRIT requirements draft > > titled, "Emergency Caller Identification". Since this section was > > requested back on 8/09, I guess I'll take a crack at > submitting some > > (proposed) text for it (below): > > > > > > "When a person places an emergency call to a PSAP, existing > emergency > > service messaging conveys associated caller information in > addition to > > receiving the caller's voice. > > This additional information typically consists of a > call-back number, > > and the caller's location (referred to as ANI and ALI, for North > > American systems)." > > > > "Some systems use the received callback number to perform a > identity > > lookup via a database lookup service, and then use the location > > information received to help verify the caller's identity presented > > both via voice, as well as the external data presented from the > > identity database query. These external mechanisms are > important for > > many reasons, including helping callers who cannot, or will > not speak, > > to prevent false information from impeding appropriate dispatch > > instructions and procedures, and ultimately to enable > faster response > > in the offering of help." > > > > "IP-based emergency systems in the future may be able to offer even > > more information about the caller, to help establish personal > > identity, but also for today, for near-term > implementations, need to > > provide the same minimum level of identitifcation support as in the > > existing legacy emergency systems." > > > > "Req1: A "Call-back" number MUST be supplied within the > call signaling > > for each emergency call sent to the PSAP. The ECRIT protocol may > > provide this number in the form of a tel:uri, a sip:uri, or an > > IP-Address." > > > > "Req2: The ECRIT protocol MUST support the ability for the PSAP to > > perform caller identity lookup based on the tel:uri, sip:uri, or IP > > Address provided with call signaling. (A variety of competing > > directory lookup services may exist, but is not discussed in detail > > here, as it is out of scope of this document.)" > > > > "Req3: The ECRIT protocol MUST support the ability to associate > > individual call location information with external caller identity > > records." > > > > > > > > I have attempted to steer clear of obvious privacy > > concerns/objections, modeling this after what's available > today in ES, > > but there are more details that some may want to tease out. > > > > Comments? > > > > Roger Marshall. > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 20 18:22:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESinj-0006Ds-QW; Thu, 20 Oct 2005 18:22:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESing-0006Dl-Ny for ecrit@megatron.ietf.org; Thu, 20 Oct 2005 18:22:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18671 for ; Thu, 20 Oct 2005 18:22:07 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESizh-0003ke-Us for ecrit@ietf.org; Thu, 20 Oct 2005 18:34:42 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 20 Oct 2005 15:22:07 -0700 X-IronPort-AV: i="3.97,238,1125903600"; d="scan'208"; a="354803462:sNHT27566454" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9KMLo9G018816; Thu, 20 Oct 2005 15:22:05 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 15:22:03 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 15:22:01 -0700 From: "Marc Linsner" To: "'Tim Dunn'" , Subject: RE: [ECRIT]: Caller Identity requirements: replacement text foremptysection in ECRIT req doc. Date: Thu, 20 Oct 2005 18:21:52 -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: AcXT3Y4AM/FQSqnNRaiWsmbORCxXIgAWwzzAAF0v0MAAAPYhgAABEgjwAAJ+qeAAATJQ4A== In-Reply-To: Message-ID: X-OriginalArrivalTime: 20 Oct 2005 22:22:02.0666 (UTC) FILETIME=[B20140A0:01C5D5C4] X-Spam-Score: 2.2 (++) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Content-Transfer-Encoding: 7bit Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Tim, I have not seen any other assertion that includes caller identity with physical location. BTW, the contact headers in SIP aren't good enough? -Marc- > -----Original Message----- > From: Tim Dunn [mailto:timothydunn01@msn.com] > Sent: Thursday, October 20, 2005 5:49 PM > To: 'Marc Linsner'; br@brianrosen.net > Cc: 'ECRIT' > Subject: RE: [ECRIT]: Caller Identity requirements: > replacement text foremptysection in ECRIT req doc. > > Marc- > > I'll express this in terms of ECRIT scope. A caller's > location is made up of 2 things: Physical location on the > ground and their identity at that physical location (i.e. > callback). What the PSAP does with the callback, I'll agree, > is out of scope. But as a part of the basic location > identity of the caller, it's location and callback. > > Tim > > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Thursday, October 20, 2005 3:06 PM > To: 'Tim Dunn'; br@brianrosen.net > Cc: 'ECRIT' > Subject: RE: [ECRIT]: Caller Identity requirements: > replacement text foremptysection in ECRIT req doc. > > Tim, > > I'm not saying that "call-back" is not a requirement. I'm > stating that it is not a requirement that ECRIT must solve. > I agree that Caller Identity > requirement(s) are necessary for proper emergency calling operations. > > ECRIT is narrowly chartered and I interpret ECRIT's charter > as 2 things: > > 1) Identify an emergency call. > > 2) Given location information, resolve to a PSAP URI. > > There will be a future document from ECRIT that outlines > various emergency calling requirements that ECRIT did > not/will not handle. I suspect Caller Identity requirement > should be in that document. > > -Marc- > > > -----Original Message----- > > From: Tim Dunn [mailto:timothydunn01@msn.com] > > Sent: Thursday, October 20, 2005 4:19 PM > > To: 'Marc Linsner'; br@brianrosen.net > > Cc: 'ECRIT' > > Subject: RE: [ECRIT]: Caller Identity requirements: > > replacement text foremptysection in ECRIT req doc. > > > > I'm assuming the charter is at: > > http://www.ietf.org/html.charters/ecrit-charter.html > > > > A very limited view read of the charter is: > > > > "Internet technologies available to describe location and to manage > > call routing." > > > > The only item explicitly out of scope is: > > > > "... the question of pre-emption or prioritization of emergency > > services traffic." > > > > I would argue that the tying the location of the caller to a way to > > re-contact that caller (especially if the call disconnects and the > > caller cannot be located) is a part of the native existing > processes > > of "...special call centers equipped to manage emergency response." > > > > The charter does say "While this group anticipates a close working > > relationship with groups such as NENA and ETSI EMTEL, any solution > > presented must be useful regardless of jurisdiction..." I'll argue > > that NENA, ETSI EMTEL or any jurisdiction that manages a > "special call > > center" would want to know why there's no standardized method to > > provide a call back number associated with a caller's > location. What > > you are proposing by eliminating a call back number is a > solution that > > could be considered out of scope because it is not useful. > > > > Tim Dunn > > > > > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Marc Linsner > > Sent: Thursday, October 20, 2005 1:45 PM > > To: br@brianrosen.net > > Cc: 'ECRIT' > > Subject: RE: [ECRIT]: Caller Identity requirements: > > replacement text foremptysection in ECRIT req doc. > > > > OK, I believe I have found the source of the "call-back' > > thread (with a little bumping from Roger). > > > > Brian, > > > > After looking over ecrit's charter again, I can't find where ecrit > > needs to worry about caller identity. I sympothize with your > > requirement, but I just can't find a place for it in ecrit. > > > > Does anybody have a different opinion?? > > > > Caller Identity going once, going twice,......... > > > > -Marc- > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Roger Marshall > > > Sent: Tuesday, October 18, 2005 7:42 PM > > > To: ECRIT > > > Subject: [ECRIT]: Caller Identity requirements: replacement > > text for > > > emptysection in ECRIT req doc. > > > > > > All: > > > There has been a placeholder within the ECRIT requirements draft > > > titled, "Emergency Caller Identification". Since this > section was > > > requested back on 8/09, I guess I'll take a crack at > > submitting some > > > (proposed) text for it (below): > > > > > > > > > "When a person places an emergency call to a PSAP, existing > > emergency > > > service messaging conveys associated caller information in > > addition to > > > receiving the caller's voice. > > > This additional information typically consists of a > > call-back number, > > > and the caller's location (referred to as ANI and ALI, for North > > > American systems)." > > > > > > "Some systems use the received callback number to perform a > > identity > > > lookup via a database lookup service, and then use the location > > > information received to help verify the caller's identity > presented > > > both via voice, as well as the external data presented from the > > > identity database query. These external mechanisms are > > important for > > > many reasons, including helping callers who cannot, or will > > not speak, > > > to prevent false information from impeding appropriate dispatch > > > instructions and procedures, and ultimately to enable > > faster response > > > in the offering of help." > > > > > > "IP-based emergency systems in the future may be able to > offer even > > > more information about the caller, to help establish personal > > > identity, but also for today, for near-term > > implementations, need to > > > provide the same minimum level of identitifcation support > as in the > > > existing legacy emergency systems." > > > > > > "Req1: A "Call-back" number MUST be supplied within the > > call signaling > > > for each emergency call sent to the PSAP. The ECRIT protocol may > > > provide this number in the form of a tel:uri, a sip:uri, or an > > > IP-Address." > > > > > > "Req2: The ECRIT protocol MUST support the ability for > the PSAP to > > > perform caller identity lookup based on the tel:uri, > sip:uri, or IP > > > Address provided with call signaling. (A variety of competing > > > directory lookup services may exist, but is not discussed > in detail > > > here, as it is out of scope of this document.)" > > > > > > "Req3: The ECRIT protocol MUST support the ability to associate > > > individual call location information with external caller > identity > > > records." > > > > > > > > > > > > I have attempted to steer clear of obvious privacy > > > concerns/objections, modeling this after what's available > > today in ES, > > > but there are more details that some may want to tease out. > > > > > > Comments? > > > > > > Roger Marshall. > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 20 19:04:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESjSM-0003Ou-PZ; Thu, 20 Oct 2005 19:04:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESjSJ-0003Nk-E9 for ecrit@megatron.ietf.org; Thu, 20 Oct 2005 19:04:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23891 for ; Thu, 20 Oct 2005 19:04:05 -0400 (EDT) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESjeI-00069N-Uj for ecrit@ietf.org; Thu, 20 Oct 2005 19:16:40 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 18:04:02 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 20 Oct 2005 18:04:01 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 18:04:02 -0500 Message-ID: From: "Winterbottom, James" To: "Marc Linsner" , "Tom-PT Taylor" Date: Thu, 20 Oct 2005 18:03:59 -0500 Subject: RE: [Ecrit] Proposed Requirement MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 20 Oct 2005 23:04:02.0106 (UTC) FILETIME=[8FB549A0:01C5D5CA] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Proposed Requirement Thread-Index: AcW9I8rqnUuW1BbARweSYy/NHW97fQBFOG6ABTdF/7AAFtKu4AAckN7QAEnvEkAAGlZ+wAAVa4Qg X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Marc, I think what it boils down to it whether the LCMS is allowed to know location AND identity. If it is, then location-by-reference must be allowed. If the LMCS is not allowed to know location AND identity, then this must be a formal requirement, otherwise the rationale is confusing and contradictory.=20 Cheers James > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Thursday, 20 October 2005 11:51 PM > To: Winterbottom, James; 'Tom-PT Taylor' > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Proposed Requirement >=20 > James, >=20 > Comments in-line.... >=20 > > > > Thank you for your response. > > If what you propose below is true, and that the LCMS is not a > > location recipient in the sense of RFC-3693, I am assuming > > that no-association between location and the user must be > > possible. Can you confirm this? >=20 > Ecrit has yet to figure out what information a LCMS client will submit to > a > LCMS server. What I am asserting is user information is certainly not > needed for LCMS to perform the requested task, matching location > information > to uri. >=20 > > If this is the case then it really needs to be a requirement > > in Roger's draft, otherwise the argument does not carry the > > weight that you purport. >=20 > I don't feel we (I) know enough to make this a requirement, yet. I'd like > more opinions on the subject of what information is required at the LCMS > server. >=20 > > > > Further to this, if the PIDF-LO contains a ruleset or ruleset > > URI, the proxy MUST not provide the location information to > > the LCMS unless the ruleset indicates that it is okay. >=20 > This is what causes heartburn. If Joe User simply 'forgets' to include > the > LCMS in his ruleset (unaware that such a service is necessary to complete > emergency calling), then his attempts to complete a properly-routed call > will fail. So my question, is the act of matching just location (no > user/host identity) to uri a breach of RFC-3693? I don't believe so, > there > is nothing interesting about 123 Main St. equals calltaker@psap.com. >=20 > This > > is exactly the same basis for location being provided for > > location-by-reference, so if it is okay to do this for > > by-value, then it MUST be okay to do it for by-reference. >=20 > Location-by-value does not equal pidf-lo. I think this is the point I'm > attempting to make: If you expect the LCMS server to dereference a > location-by-reference, the LCMS server MUST be in the ruleset. > Alternatively, if the proxy (LCMS client) performs dereference and uses > only > the location-by-value data (no user identity) then the LCMS server does > not > fall under the definition of location-recipient spelled out in RFC-3693. > Obviously, if Joe User forgets to include his proxy in the ruleset, then > the > proper call-routing will fail as the proxy cannot dereference the LBR. >=20 > > > > A note of warning, if the LCMS MUST not be able to associate > > location with user identity, then sending a PIDF-LO to the > > LCMS where the value for the presentity parameter is > > traceable to the user's true identity will be not acceptable. > > This implies that the proxy will need to understand this. >=20 > Again, the pidf-lo contains way more data than necessary for LCMS to > perform > it's task, IMO. >=20 > Thanks, >=20 > -Marc- >=20 ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 20 19:45:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESk6U-0008PC-IR; Thu, 20 Oct 2005 19:45:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESk6T-0008MR-8P for ecrit@megatron.ietf.org; Thu, 20 Oct 2005 19:45:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09387 for ; Thu, 20 Oct 2005 19:45:33 -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.43) id 1ESk8m-0004hT-MU for ecrit@ietf.org; Thu, 20 Oct 2005 19:48:09 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 20 Oct 2005 16:35:33 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9KNZT96025498; Thu, 20 Oct 2005 16:35:31 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 16:35:28 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 16:35:28 -0700 From: "Marc Linsner" To: "'Winterbottom, James'" , "'Tom-PT Taylor'" Subject: RE: [Ecrit] Proposed Requirement Date: Thu, 20 Oct 2005 19:35:18 -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: AcW9I8rqnUuW1BbARweSYy/NHW97fQBFOG6ABTdF/7AAFtKu4AAckN7QAEnvEkAAGlZ+wAAVa4QgAAEdcwA= In-Reply-To: Message-ID: X-OriginalArrivalTime: 20 Oct 2005 23:35:28.0367 (UTC) FILETIME=[F401DFF0:01C5D5CE] X-Spam-Score: 1.1 (+) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org James, There is one more point I'm trying to make. If the LCMS knows location and identity, then it falls under the rules of RFC-3693. This is something I'm advocating is not necessary for LCMS to complete it's assigned task. -Marc- > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Thursday, October 20, 2005 7:04 PM > To: Marc Linsner; Tom-PT Taylor > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Proposed Requirement > > Marc, > > I think what it boils down to it whether the LCMS is allowed > to know location AND identity. If it is, then > location-by-reference must be allowed. If the LMCS is not > allowed to know location AND identity, then this must be a > formal requirement, otherwise the rationale is confusing and > contradictory. > > Cheers > James > > > > -----Original Message----- > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > Sent: Thursday, 20 October 2005 11:51 PM > > To: Winterbottom, James; 'Tom-PT Taylor' > > Cc: ecrit@ietf.org > > Subject: RE: [Ecrit] Proposed Requirement > > > > James, > > > > Comments in-line.... > > > > > > > > Thank you for your response. > > > If what you propose below is true, and that the LCMS is not a > > > location recipient in the sense of RFC-3693, I am assuming that > > > no-association between location and the user must be > possible. Can > > > you confirm this? > > > > Ecrit has yet to figure out what information a LCMS client > will submit > to > > a > > LCMS server. What I am asserting is user information is > certainly not > > needed for LCMS to perform the requested task, matching location > > information to uri. > > > > > If this is the case then it really needs to be a requirement in > > > Roger's draft, otherwise the argument does not carry the > weight that > > > you purport. > > > > I don't feel we (I) know enough to make this a requirement, > yet. I'd > like > > more opinions on the subject of what information is required at the > LCMS > > server. > > > > > > > > Further to this, if the PIDF-LO contains a ruleset or > ruleset URI, > > > the proxy MUST not provide the location information to the LCMS > > > unless the ruleset indicates that it is okay. > > > > This is what causes heartburn. If Joe User simply 'forgets' to > include > > the > > LCMS in his ruleset (unaware that such a service is necessary to > complete > > emergency calling), then his attempts to complete a properly-routed > call > > will fail. So my question, is the act of matching just > location (no > > user/host identity) to uri a breach of RFC-3693? I don't > believe so, > > there is nothing interesting about 123 Main St. equals > > calltaker@psap.com. > > > > This > > > is exactly the same basis for location being provided for > > > location-by-reference, so if it is okay to do this for by-value, > > > then it MUST be okay to do it for by-reference. > > > > Location-by-value does not equal pidf-lo. I think this is the point > I'm > > attempting to make: If you expect the LCMS server to dereference a > > location-by-reference, the LCMS server MUST be in the ruleset. > > Alternatively, if the proxy (LCMS client) performs dereference and > uses > > only > > the location-by-value data (no user identity) then the LCMS server > does > > not > > fall under the definition of location-recipient spelled out in > RFC-3693. > > Obviously, if Joe User forgets to include his proxy in the ruleset, > then > > the > > proper call-routing will fail as the proxy cannot > dereference the LBR. > > > > > > > > A note of warning, if the LCMS MUST not be able to associate > > > location with user identity, then sending a PIDF-LO to the LCMS > > > where the value for the presentity parameter is traceable to the > > > user's true identity will be not acceptable. > > > This implies that the proxy will need to understand this. > > > > Again, the pidf-lo contains way more data than necessary > for LCMS to > > perform it's task, IMO. > > > > Thanks, > > > > -Marc- > > > > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 20 20:04:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESkOM-0004MU-FE; Thu, 20 Oct 2005 20:04:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESkNo-00047d-KO for ecrit@megatron.ietf.org; Thu, 20 Oct 2005 20:03:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11506 for ; Thu, 20 Oct 2005 20:03:29 -0400 (EDT) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESkKj-0007A2-4r for ecrit@ietf.org; Thu, 20 Oct 2005 20:00:29 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 18:47:53 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 20 Oct 2005 18:47:25 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 18:47:25 -0500 Message-ID: From: "Winterbottom, James" To: "Marc Linsner" , "Tom-PT Taylor" Date: Thu, 20 Oct 2005 18:47:23 -0500 Subject: RE: [Ecrit] Proposed Requirement MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 20 Oct 2005 23:47:25.0192 (UTC) FILETIME=[9F44B080:01C5D5D0] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Proposed Requirement Thread-Index: AcW9I8rqnUuW1BbARweSYy/NHW97fQBFOG6ABTdF/7AAFtKu4AAckN7QAEnvEkAAGlZ+wAAVa4QgAAEdcwAAAH4gUA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Okay, then let's make it a hard requirement so the debate can end and specifications of mapping protocols can continue. > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Friday, 21 October 2005 9:35 AM > To: Winterbottom, James; 'Tom-PT Taylor' > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Proposed Requirement >=20 > James, >=20 > There is one more point I'm trying to make. If the LCMS knows location > and > identity, then it falls under the rules of RFC-3693. This is something > I'm > advocating is not necessary for LCMS to complete it's assigned task. >=20 > -Marc- >=20 > > -----Original Message----- > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: Thursday, October 20, 2005 7:04 PM > > To: Marc Linsner; Tom-PT Taylor > > Cc: ecrit@ietf.org > > Subject: RE: [Ecrit] Proposed Requirement > > > > Marc, > > > > I think what it boils down to it whether the LCMS is allowed > > to know location AND identity. If it is, then > > location-by-reference must be allowed. If the LMCS is not > > allowed to know location AND identity, then this must be a > > formal requirement, otherwise the rationale is confusing and > > contradictory. > > > > Cheers > > James > > > > > > > -----Original Message----- > > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > > Sent: Thursday, 20 October 2005 11:51 PM > > > To: Winterbottom, James; 'Tom-PT Taylor' > > > Cc: ecrit@ietf.org > > > Subject: RE: [Ecrit] Proposed Requirement > > > > > > James, > > > > > > Comments in-line.... > > > > > > > > > > > Thank you for your response. > > > > If what you propose below is true, and that the LCMS is not a > > > > location recipient in the sense of RFC-3693, I am assuming that > > > > no-association between location and the user must be > > possible. Can > > > > you confirm this? > > > > > > Ecrit has yet to figure out what information a LCMS client > > will submit > > to > > > a > > > LCMS server. What I am asserting is user information is > > certainly not > > > needed for LCMS to perform the requested task, matching location > > > information to uri. > > > > > > > If this is the case then it really needs to be a requirement in > > > > Roger's draft, otherwise the argument does not carry the > > weight that > > > > you purport. > > > > > > I don't feel we (I) know enough to make this a requirement, > > yet. I'd > > like > > > more opinions on the subject of what information is required at the > > LCMS > > > server. > > > > > > > > > > > Further to this, if the PIDF-LO contains a ruleset or > > ruleset URI, > > > > the proxy MUST not provide the location information to the LCMS > > > > unless the ruleset indicates that it is okay. > > > > > > This is what causes heartburn. If Joe User simply 'forgets' to > > include > > > the > > > LCMS in his ruleset (unaware that such a service is necessary to > > complete > > > emergency calling), then his attempts to complete a properly-routed > > call > > > will fail. So my question, is the act of matching just > > location (no > > > user/host identity) to uri a breach of RFC-3693? I don't > > believe so, > > > there is nothing interesting about 123 Main St. equals > > > calltaker@psap.com. > > > > > > This > > > > is exactly the same basis for location being provided for > > > > location-by-reference, so if it is okay to do this for by-value, > > > > then it MUST be okay to do it for by-reference. > > > > > > Location-by-value does not equal pidf-lo. I think this is the point > > I'm > > > attempting to make: If you expect the LCMS server to dereference a > > > location-by-reference, the LCMS server MUST be in the ruleset. > > > Alternatively, if the proxy (LCMS client) performs dereference and > > uses > > > only > > > the location-by-value data (no user identity) then the LCMS server > > does > > > not > > > fall under the definition of location-recipient spelled out in > > RFC-3693. > > > Obviously, if Joe User forgets to include his proxy in the ruleset, > > then > > > the > > > proper call-routing will fail as the proxy cannot > > dereference the LBR. > > > > > > > > > > > A note of warning, if the LCMS MUST not be able to associate > > > > location with user identity, then sending a PIDF-LO to the LCMS > > > > where the value for the presentity parameter is traceable to the > > > > user's true identity will be not acceptable. > > > > This implies that the proxy will need to understand this. > > > > > > Again, the pidf-lo contains way more data than necessary > > for LCMS to > > > perform it's task, IMO. > > > > > > Thanks, > > > > > > -Marc- > > > > > > > -------------------------------------------------------------- > > ---------------------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > -------------------------------------------------------------- > > ---------------------------------- > > [mf2] ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 20 21:57:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESmA4-0006uC-Pt; Thu, 20 Oct 2005 21:57:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESmA2-0006u4-OC for ecrit@megatron.ietf.org; Thu, 20 Oct 2005 21:57:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16827 for ; Thu, 20 Oct 2005 21:57:20 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESmM1-0003P5-6r for ecrit@ietf.org; Thu, 20 Oct 2005 22:09:58 -0400 Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net [141.153.174.94]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j9L1vN7C005672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Oct 2005 21:57:23 -0400 (EDT) Message-ID: <43584B20.4080607@cs.columbia.edu> Date: Thu, 20 Oct 2005 21:57:52 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Dunn Subject: Re: [ECRIT]: Caller Identity requirements: replacement text foremptysection in ECRIT req doc. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Just to rephrase slightly what Marc has said: I think there is general agreement that call signaling and civic/geo-address-to-URL mapping are independent and thus it seems unnecessary (and potentially a privacy violation) for the mapping protocol to know anything about the caller's identity, call back number or other similar non-location information. (Maybe an explicit scope disclaimer in the requirements document would be helpful.) Tim Dunn wrote: > Marc- > > I'll express this in terms of ECRIT scope. A caller's location is made up > of 2 things: Physical location on the ground and their identity at that > physical location (i.e. callback). What the PSAP does with the callback, > I'll agree, is out of scope. But as a part of the basic location identity > of the caller, it's location and callback. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 20 22:25:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESmbN-0007Cp-Sk; Thu, 20 Oct 2005 22:25:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESmbL-00079k-R3 for ecrit@megatron.ietf.org; Thu, 20 Oct 2005 22:25:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18025 for ; Thu, 20 Oct 2005 22:25:36 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESmnO-0004CW-I4 for ecrit@ietf.org; Thu, 20 Oct 2005 22:38:15 -0400 Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net [141.153.174.94]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j9L2Pi90009330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Oct 2005 22:25:45 -0400 (EDT) Message-ID: <435851C7.4070807@cs.columbia.edu> Date: Thu, 20 Oct 2005 22:26:15 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: br@brianrosen.net Subject: Re: [ECRIT]: Caller Identity requirements: replacement textforemptysection in ECRIT req doc. References: <0a7201c5d5a6$63624840$640fa8c0@cis.neustar.com> In-Reply-To: <0a7201c5d5a6$63624840$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.2 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian Rosen wrote: > If not ecrit (which I'll accept), then which work group do we take this > requirement. > This seems to depend on the protocol. If I signal via SIP, the Contact header (either traditional or GRUU-style) is the call-back and the From header is the long-term call back. Thus, at best somebody would have to say, BCPish, to please include Contact information. This might fit into Henry's client requirements document, for example. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 20 22:42:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESmr2-000098-Fr; Thu, 20 Oct 2005 22:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESmqz-00008x-7T for ecrit@megatron.ietf.org; Thu, 20 Oct 2005 22:41:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18699 for ; Thu, 20 Oct 2005 22:41:46 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESn31-0004hn-VL for ecrit@ietf.org; Thu, 20 Oct 2005 22:54:25 -0400 Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net [141.153.174.94]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j9L2fsbY004632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Oct 2005 22:41:54 -0400 (EDT) Message-ID: <43585592.1060705@cs.columbia.edu> Date: Thu, 20 Oct 2005 22:42:26 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Abbott, Nadine B" Subject: Re: [Ecrit] Issue 15 (civic location validation) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.2 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Nadine, I can't speak for the proponents of other solutions, but in my LUMP proposal, validation is built into the system and does not require a separate mechanism. (It may be useful to provide flags requesting specific matching behavior, although I think most of this can be handled by appropriate 'warning' responses.) Given that almost all of the information in lookup and validation are the same, I think the overall system complexity would increase by separating the two. Plus, one might argue that this would open up an opportunity for the validation to succeed, while the "real" query doesn't, or vice versa. Henning Abbott, Nadine B wrote: > Henning, > > In the migratory work done on location validation in NENA, we allowed > for several cases: > - Match > - Match, after some processing (e.g., adjustments in > abbreviations, etc., this distinction is not so important as the next > two, I think) > - Ambiguous match (more than one match at some level (this would > be your "known not to exist", I believe) > - No match (this would be your "did not match", I believe). > > In the failure cases, the location validation response may return some > assistance: > e.g., for ambiguous match, we allow for return some of the best > alternative possible matches; > for ambiguous match and no match, we allow for return of a URI > where more help might be available to create a valid address. > > I wonder if it might be possible to consider whether the mapping > protocol could provide a set of similar responses, or at least provide a > URI(s) for where the mapping client might go for the kind of support > available in the migratory solution? > > The NENA migratory solution for this function uses standard Web Services > protocol. > Is there any interest in leveraging any of this work? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 20 22:56:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESn4o-0007oc-Lm; Thu, 20 Oct 2005 22:56:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESn4o-0007oX-4L for ecrit@megatron.ietf.org; Thu, 20 Oct 2005 22:56:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19150 for ; Thu, 20 Oct 2005 22:56:02 -0400 (EDT) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESnGq-00055K-N9 for ecrit@ietf.org; Thu, 20 Oct 2005 23:08:42 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 21:55:59 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 20 Oct 2005 21:55:59 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 21:55:59 -0500 Message-ID: From: "Winterbottom, James" To: "Henning Schulzrinne" , "Abbott, Nadine B" Date: Thu, 20 Oct 2005 21:55:57 -0500 Subject: RE: [Ecrit] Issue 15 (civic location validation) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 21 Oct 2005 02:55:59.0133 (UTC) FILETIME=[F6E714D0:01C5D5EA] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Issue 15 (civic location validation) Thread-Index: AcXV6UOHPTQop8rSSl2DVR+6PqdDOQAAPfgg X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I wonder if the LUMP concept and NENA i2 validation concept aren't quite different things. I see the NENA i2 validation as a precursory step to storing location in database to be handed out to clients on request to ensure that a route can be determined for it. LUMP and the ECRIT mapping protocol is much more in line with the behaviour of the VPC/ERDB functionality, that is, given a location please provide a route to a destination. I don't think that the ERDB protocol supports a partial match concept, it either works, it fails, or it may redirect. Or have I missed the point? James > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Henning Schulzrinne > Sent: Friday, 21 October 2005 12:42 PM > To: Abbott, Nadine B > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Issue 15 (civic location validation) >=20 > Nadine, >=20 > I can't speak for the proponents of other solutions, but in my LUMP > proposal, validation is built into the system and does not require a > separate mechanism. (It may be useful to provide flags requesting > specific matching behavior, although I think most of this can be handled > by appropriate 'warning' responses.) >=20 > Given that almost all of the information in lookup and validation are > the same, I think the overall system complexity would increase by > separating the two. Plus, one might argue that this would open up an > opportunity for the validation to succeed, while the "real" query > doesn't, or vice versa. >=20 > Henning >=20 > Abbott, Nadine B wrote: > > Henning, > > > > In the migratory work done on location validation in NENA, we allowed > > for several cases: > > - Match > > - Match, after some processing (e.g., adjustments in > > abbreviations, etc., this distinction is not so important as the next > > two, I think) > > - Ambiguous match (more than one match at some level (this would > > be your "known not to exist", I believe) > > - No match (this would be your "did not match", I believe). > > > > In the failure cases, the location validation response may return some > > assistance: > > e.g., for ambiguous match, we allow for return some of the best > > alternative possible matches; > > for ambiguous match and no match, we allow for return of a URI > > where more help might be available to create a valid address. > > > > I wonder if it might be possible to consider whether the mapping > > protocol could provide a set of similar responses, or at least provide a > > URI(s) for where the mapping client might go for the kind of support > > available in the migratory solution? > > > > The NENA migratory solution for this function uses standard Web Services > > protocol. > > Is there any interest in leveraging any of this work? >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 20 23:04:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESnDB-0003gQ-Kw; Thu, 20 Oct 2005 23:04:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESnD9-0003gI-L7 for ecrit@megatron.ietf.org; Thu, 20 Oct 2005 23:04:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19459 for ; Thu, 20 Oct 2005 23:04:40 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESnPC-0005JX-OT for ecrit@ietf.org; Thu, 20 Oct 2005 23:17:19 -0400 Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net [141.153.174.94]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j9L34fvo007371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Oct 2005 23:04:49 -0400 (EDT) Message-ID: <43585AEA.3080104@cs.columbia.edu> Date: Thu, 20 Oct 2005 23:05:14 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Winterbottom, James" Subject: Re: [Ecrit] Issue 15 (civic location validation) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.2 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org It's hard to discuss this in the abstract, but I think they are essentially the same. Input: location (geo or civic) in both cases Output: URL(s) and possible warnings about approximations made or a failure indication if no (unique) match is possible I think having the warning is useful even in the "real" resolution since this can be used for debugging. As hard as we try, we can't rule out that somebody injects partially-incorrect location information into the system. As a slightly contrived example, imagine that I validate "123 Main Street". At the time of validation, the validation system only knows that "100-500 Main Street" exists, based on MSAG data, and thus returns a valid response. If I then make a real call a week later, with the same address and the mapping database has been updated to capture individual house numbers, 123 Main Street may no longer be (strictly) valid. Henning Winterbottom, James wrote: > I wonder if the LUMP concept and NENA i2 validation concept aren't quite > different things. I see the NENA i2 validation as a precursory step to > storing location in database to be handed out to clients on request to > ensure that a route can be determined for it. LUMP and the ECRIT mapping > protocol is much more in line with the behaviour of the VPC/ERDB > functionality, that is, given a location please provide a route to a > destination. I don't think that the ERDB protocol supports a partial > match concept, it either works, it fails, or it may redirect. Or have I > missed the point? > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 20 23:34:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESngI-0002cH-Bg; Thu, 20 Oct 2005 23:34:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESngG-0002aj-EZ for ecrit@megatron.ietf.org; Thu, 20 Oct 2005 23:34:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20764 for ; Thu, 20 Oct 2005 23:34:45 -0400 (EDT) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESnsJ-0006DQ-Ob for ecrit@ietf.org; Thu, 20 Oct 2005 23:47:25 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 22:34:46 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 20 Oct 2005 22:34:46 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 22:34:45 -0500 Message-ID: From: "Winterbottom, James" To: "Henning Schulzrinne" Date: Thu, 20 Oct 2005 22:34:44 -0500 Subject: RE: [Ecrit] Issue 15 (civic location validation) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 21 Oct 2005 03:34:45.0509 (UTC) FILETIME=[6187E350:01C5D5F0] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Issue 15 (civic location validation) Thread-Index: AcXV7DPLVA71wfYmQnm1FNIqZ7svJAAASewA X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Henning, I guess that I had assumed that one would only provision down to the coarsest level of information required to get the call to where it needs to go. So while your example is a contrived one, for call routing does it really matter? For display purposes at the PSAP it is a different matter, but it is also out of scope. Given this, I would be a little bit concerned about firstly the real value of providing such warnings (to whom are they provided, and how are they to be actioned), and secondly the potential processing costs to produce. Cheers James > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, 21 October 2005 1:05 PM > To: Winterbottom, James > Cc: Abbott, Nadine B; ecrit@ietf.org > Subject: Re: [Ecrit] Issue 15 (civic location validation) >=20 > It's hard to discuss this in the abstract, but I think they are > essentially the same. >=20 > Input: location (geo or civic) in both cases > Output: URL(s) and possible warnings about approximations made or a > failure indication if no (unique) match is possible >=20 > I think having the warning is useful even in the "real" resolution since > this can be used for debugging. As hard as we try, we can't rule out > that somebody injects partially-incorrect location information into the > system. As a slightly contrived example, imagine that I validate "123 > Main Street". At the time of validation, the validation system only > knows that "100-500 Main Street" exists, based on MSAG data, and thus > returns a valid response. If I then make a real call a week later, with > the same address and the mapping database has been updated to capture > individual house numbers, 123 Main Street may no longer be (strictly) > valid. >=20 > Henning ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 20 23:43:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESnoT-0002QC-8a; Thu, 20 Oct 2005 23:43:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESnoR-0002Q4-7N for ecrit@megatron.ietf.org; Thu, 20 Oct 2005 23:43:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21236 for ; Thu, 20 Oct 2005 23:43:11 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESo0U-0006WS-0M for ecrit@ietf.org; Thu, 20 Oct 2005 23:55:51 -0400 Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net [141.153.174.94]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j9L3h0tN018795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Oct 2005 23:43:07 -0400 (EDT) Message-ID: <435863E8.2030402@cs.columbia.edu> Date: Thu, 20 Oct 2005 23:43:36 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Winterbottom, James" Subject: Re: [Ecrit] Issue 15 (civic location validation) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 1.2 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Winterbottom, James wrote: > > Hi Henning, > > I guess that I had assumed that one would only provision down to the > coarsest level of information required to get the call to where it needs > to go. So while your example is a contrived one, for call routing does > it really matter? For display purposes at the PSAP it is a different > matter, but it is also out of scope. Since there's no cost in doing this validation, it seems counterproductive to disallow it. In addition, PSAP boundaries sometimes change. If you didn't validate the 123 part of Main Street before and you now split Main Street, with 1-50 in one PSAP and 50-99 in another (and 123 invalid), you have a problem. Again, not likely, but why make the system worse than it has to be, at no decrease in complexity? > > Given this, I would be a little bit concerned about firstly the real > value of providing such warnings (to whom are they provided, and how are > they to be actioned), and secondly the potential processing costs to > produce. I think processing costs are a non-issue, as the database lookup cost on a longer key is essentially the same as on one slightly smaller key (they just get hashed). In any event, this is a protocol functionality. If a particular implementation or installation wants to ignore all but the city, for example, it can choose to do that, with the appropriate indication. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 21 00:19:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESoNF-0006nW-64; Fri, 21 Oct 2005 00:19:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESoND-0006nO-8J for ecrit@megatron.ietf.org; Fri, 21 Oct 2005 00:19:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23451 for ; Fri, 21 Oct 2005 00:19:09 -0400 (EDT) Received: from bay106-f30.bay106.hotmail.com ([65.54.161.40] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESoZG-0007vt-Kj for ecrit@ietf.org; Fri, 21 Oct 2005 00:31:48 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 20 Oct 2005 21:19:08 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Fri, 21 Oct 2005 04:19:07 GMT X-Originating-IP: [70.59.41.142] X-Originating-Email: [timothydunn01@msn.com] X-Sender: timothydunn01@msn.com In-Reply-To: <43584B20.4080607@cs.columbia.edu> From: "Tim DUNN" To: hgs@cs.columbia.edu Subject: Re: [ECRIT]: Caller Identity requirements: replacement text foremptysection in ECRIT req doc. Date: Thu, 20 Oct 2005 22:19:07 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 21 Oct 2005 04:19:08.0424 (UTC) FILETIME=[94C07880:01C5D5F6] X-Spam-Score: 2.8 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The PSAP needs is a location and a call back. Not providing both is a reduction in existing capabilities in place for circuit switched and mobile 911 calls. Both need to be accounted for somewhere in this overall set of requirements/architecture. >From: Henning Schulzrinne >To: Tim Dunn >CC: "'Marc Linsner'" , br@brianrosen.net, >"'ECRIT'" >Subject: Re: [ECRIT]: Caller Identity requirements: replacement >text foremptysection in ECRIT req doc. >Date: Thu, 20 Oct 2005 21:57:52 -0400 > >Just to rephrase slightly what Marc has said: I think there is general >agreement that call signaling and civic/geo-address-to-URL mapping are >independent and thus it seems unnecessary (and potentially a privacy >violation) for the mapping protocol to know anything about the caller's >identity, call back number or other similar non-location information. > >(Maybe an explicit scope disclaimer in the requirements document would be >helpful.) > >Tim Dunn wrote: >>Marc- >> >>I'll express this in terms of ECRIT scope. A caller's location is made up >>of 2 things: Physical location on the ground and their identity at that >>physical location (i.e. callback). What the PSAP does with the callback, >>I'll agree, is out of scope. But as a part of the basic location identity >>of the caller, it's location and callback. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 21 08:58:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESwTN-0004CU-3S; Fri, 21 Oct 2005 08:58:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESwTL-0004C7-0d for ecrit@megatron.ietf.org; Fri, 21 Oct 2005 08:58:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19850 for ; Fri, 21 Oct 2005 08:58:00 -0400 (EDT) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESwfU-0008Hs-8E for ecrit@ietf.org; Fri, 21 Oct 2005 09:10:44 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1ESwT2-0008Dx-7G; Fri, 21 Oct 2005 07:57:52 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Winterbottom, James'" Subject: RE: [Ecrit] Issue 15 (civic location validation) Date: Fri, 21 Oct 2005 08:57:15 -0400 Message-ID: <0edd01c5d63e$f7f879a0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <435863E8.2030402@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXV8eEURRPsxnjeRiWhOSGxK36DWQASnZtA X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.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: 1.0 (+) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I believe they are essentially identical functions, where the differences are small enough that in the code it doesn't matter. NENA made them separate for what I believe were not good enough reasons. In actuality, in both cases, you try a direct match with what you are given. If you get a "hit", you return "good". The fact that "good" for validation is literally a single bit, while in the mapping case you get a URI is an imperceptible difference. If you don't get a hit, you start eliminating fields, starting at the most specific and working your way back until you find a match. For validation, depending on where you find a match, you may select all the values of the next most specific field to offer as alternatives (East Main St, West Main St). For mapping, you return the "default route" for the valid field you got to. That's a difference, but not much of one. There is possibly one difference that matters. There are far more queries to the validation database than to the mapping database IF the mapping is delayed to the time of a call. You can make an argument that you don't want to have run-away validation queries getting in the way of mapping queries, which argues for separate actual databases. My view is that mapping is done, and cached early, and also done at call time, so the number of queries for the mapping is likely higher than for validation, and this argument would not hold. NENA i2 only has call time mapping, so it works there. You also don't require the same reliability in the validation query as the mapping query (say 3 nines instead of 5 nines). Not clear this makes a big difference these days. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Thursday, October 20, 2005 11:44 PM To: Winterbottom, James Cc: ecrit@ietf.org Subject: Re: [Ecrit] Issue 15 (civic location validation) Winterbottom, James wrote: > > Hi Henning, > > I guess that I had assumed that one would only provision down to the > coarsest level of information required to get the call to where it needs > to go. So while your example is a contrived one, for call routing does > it really matter? For display purposes at the PSAP it is a different > matter, but it is also out of scope. Since there's no cost in doing this validation, it seems counterproductive to disallow it. In addition, PSAP boundaries sometimes change. If you didn't validate the 123 part of Main Street before and you now split Main Street, with 1-50 in one PSAP and 50-99 in another (and 123 invalid), you have a problem. Again, not likely, but why make the system worse than it has to be, at no decrease in complexity? > > Given this, I would be a little bit concerned about firstly the real > value of providing such warnings (to whom are they provided, and how are > they to be actioned), and secondly the potential processing costs to > produce. I think processing costs are a non-issue, as the database lookup cost on a longer key is essentially the same as on one slightly smaller key (they just get hashed). In any event, this is a protocol functionality. If a particular implementation or installation wants to ignore all but the city, for example, it can choose to do that, with the appropriate indication. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 21 09:04:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESwZ8-0007ZA-Lu; Fri, 21 Oct 2005 09:04:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESwZ6-0007Vj-DN for ecrit@megatron.ietf.org; Fri, 21 Oct 2005 09:04:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20277 for ; Fri, 21 Oct 2005 09:03:57 -0400 (EDT) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESwlF-000058-M2 for ecrit@ietf.org; Fri, 21 Oct 2005 09:16:41 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1ESwYw-0000Gi-KX for ecrit@ietf.org; Fri, 21 Oct 2005 08:03:59 -0500 From: "Brian Rosen" To: Date: Fri, 21 Oct 2005 09:03:22 -0400 Message-ID: <0ede01c5d63f$d26f9960$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXV4afEGETiw7IqTJ2ZjjF4SYQaLgAXhg0w X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.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: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Subject: [Ecrit] Location by Reference considered harmful for Emergency Calls X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I'd like to challenge the entire notion of location by reference for emergency calls. What you want for emergency calls is for it to work when things go wrong. If you don't have location, you can't route, and because it's the Internet, that means you don't know what continent you are in, let alone which PSAP you need to go to. Location by reference means that we can't figure out where you are unless we can dereference the location. When things go wrong, you can lose connectivity. This is related to Henning's requirement about if there is connectivity between the PSAP and the UA, it ought to work. Loss of connectivity to the LIS has two bad characteristics: 1. You may not be able to get the location at the time of the call to route. That affects both the first mapping and any subsequent routing due to, for example, an ESRP. 2. The PSAP might not be able to get the location, because it can't get to the LIS. The first characteristic can be migrated somewhat by mapping early, before the call. This may fix the first route, but not anything the ESRP does. If the first route is fixed, we probably have a gross idea of where you are (say, a state level), but nothing that is really helpful to route. The second characteristic can't be mitigated at all. I also don't like adding entities that have to be reliable at call time. We need some, but fewer is better. It seems to me that, for emergency calls, we have to have a really big overriding reason that trumps this issue. I don't see it; location by reference is just a nice to have because it bits the signaling is carrying smaller, and it gives the LIS operator more control over the location. In the emergency calling domain, those are much less important than reliability of route and location delivery to the PSAP. And as was pointed out, you can't use the first dereference, and then send location so that downstream entities can use it directly; proxies can't add bodies. Location by reference may have more value in other use cases, where the extreme reliability is not much of a concern. If location by reference had a requirement that the endpoint that has a location must be able to dereference itself (i.e., you can always ask where you are), then the endpoint could do the dereference at, say, boot time, and then use location by value for emergency calls. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 21 09:26:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESwv3-000232-D4; Fri, 21 Oct 2005 09:26:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESwv2-00022o-8q for ecrit@megatron.ietf.org; Fri, 21 Oct 2005 09:26:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21267 for ; Fri, 21 Oct 2005 09:26:37 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESx79-0000nF-J7 for ecrit@ietf.org; Fri, 21 Oct 2005 09:39:20 -0400 Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net [141.153.174.94]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j9LDQidU003749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 Oct 2005 09:26:44 -0400 (EDT) Message-ID: <4358EC3F.4090605@cs.columbia.edu> Date: Fri, 21 Oct 2005 09:25:19 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim DUNN Subject: Re: [ECRIT]: Caller Identity requirements: replacement text foremptysection in ECRIT req doc. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Tim DUNN wrote: > The PSAP needs is a location and a call back. Not providing both is a > reduction in existing capabilities in place for circuit switched and > mobile 911 calls. Both need to be accounted for somewhere in this > overall set of requirements/architecture. > It's pretty simple: The call setup request reaching the PSAP provides call back information and location information, in-band. I agree with the need for an architecture document; I've written (long-expired) versions of something approximating those. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 21 09:35:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESx3g-0006pC-5X; Fri, 21 Oct 2005 09:35:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESx3e-0006oh-Pm for ecrit@megatron.ietf.org; Fri, 21 Oct 2005 09:35:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21750 for ; Fri, 21 Oct 2005 09:35:32 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESxFo-00017C-91 for ecrit@ietf.org; Fri, 21 Oct 2005 09:48:16 -0400 Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net [141.153.174.94]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j9LDZRis006703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 Oct 2005 09:35:40 -0400 (EDT) Message-ID: <4358EE49.5020300@cs.columbia.edu> Date: Fri, 21 Oct 2005 09:34:01 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: br@brianrosen.net Subject: Re: [Ecrit] Location by Reference considered harmful for Emergency Calls References: <0ede01c5d63f$d26f9960$640fa8c0@cis.neustar.com> In-Reply-To: <0ede01c5d63f$d26f9960$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.2 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org There is an additional, smaller problem, namely reference validity. Once you have a reference, all parties better understand how long the reference is valid and retrievable. If the reference times out and the call gets transferred to a first responder, there's a problem. I'm sure this can be solved, but it introduces yet another failure case. There's also a privacy issue: As soon as the PSAP requests location by reference, the location provider now knows that I placed an emergency call. This is not information that I'd necessarily want to share with parties that I barely know. Henning Brian Rosen wrote: > I'd like to challenge the entire notion of location by reference for > emergency calls. > > What you want for emergency calls is for it to work when things go wrong. > > If you don't have location, you can't route, and because it's the Internet, > that means you don't know what continent you are in, let alone which PSAP > you need to go to. > > Location by reference means that we can't figure out where you are unless we > can dereference the location. When things go wrong, you can lose > connectivity. This is related to Henning's requirement about if there is > connectivity between the PSAP and the UA, it ought to work. > > Loss of connectivity to the LIS has two bad characteristics: > > 1. You may not be able to get the location at the time of the call to route. > That affects both the first mapping and any subsequent routing due to, for > example, an ESRP. > 2. The PSAP might not be able to get the location, because it can't get to > the LIS. > > The first characteristic can be migrated somewhat by mapping early, before > the call. This may fix the first route, but not anything the ESRP does. If > the first route is fixed, we probably have a gross idea of where you are > (say, a state level), but nothing that is really helpful to route. > > The second characteristic can't be mitigated at all. > > I also don't like adding entities that have to be reliable at call time. We > need some, but fewer is better. > > It seems to me that, for emergency calls, we have to have a really big > overriding reason that trumps this issue. I don't see it; location by > reference is just a nice to have because it bits the signaling is carrying > smaller, and it gives the LIS operator more control over the location. In > the emergency calling domain, those are much less important than reliability > of route and location delivery to the PSAP. > > And as was pointed out, you can't use the first dereference, and then send > location so that downstream entities can use it directly; proxies can't add > bodies. > > Location by reference may have more value in other use cases, where the > extreme reliability is not much of a concern. > > If location by reference had a requirement that the endpoint that has a > location must be able to dereference itself (i.e., you can always ask where > you are), then the endpoint could do the dereference at, say, boot time, and > then use location by value for emergency calls. > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 21 10:00:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESxRK-0001jF-9n; Fri, 21 Oct 2005 10:00:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESxRI-0001f5-Jt for ecrit@megatron.ietf.org; Fri, 21 Oct 2005 10:00:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23157 for ; Fri, 21 Oct 2005 09:59:57 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESxdP-000213-8V for ecrit@ietf.org; Fri, 21 Oct 2005 10:12:42 -0400 Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net [141.153.174.94]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j9LE02MN018237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 Oct 2005 10:00:02 -0400 (EDT) Message-ID: <4358F407.7050202@cs.columbia.edu> Date: Fri, 21 Oct 2005 09:58:31 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: br@brianrosen.net Subject: Re: [Ecrit] Issue 15 (civic location validation) References: <0edd01c5d63e$f7f879a0$640fa8c0@cis.neustar.com> In-Reply-To: <0edd01c5d63e$f7f879a0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.2 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > > You also don't require the same reliability in the validation query as the > mapping query (say 3 nines instead of 5 nines). Not clear this makes a big > difference these days. I would argue that reliability argues for integration. Validation works both ways: "my civic/geo address is valid" and "mapping would work if tried". If validation goes to some different place and uses different code, you can't be sure that the real mapping would work. Plus, if we assume that end system obtain a mapping at boot time rather than at call time, separating the two seems a bit strange. You'd do the mapping (which also tells you if the address is valid) and then occasionally also ask a validator. (Nomadic systems would presumably do mapping and validation each time they connect.) Not sure what good that would accomplish, besides extra end system complexity and error cases. In addition, it's not clear to me how you could afford a less reliable validation system. For the not-unlikely case where you plug in your nomadic network device to make an emergency call, validation better work as reliably as mapping and better not add delay. In general, it's easier to make a single system reliable than to have two, since a single, larger system has more total resources that can be shared and spared. Based on (painful) experience, simplicity and generality wins. For SIP, I wish we would have pushed back harder on doing things several ways in a number of places. I'm trying to learn from that experience... Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 21 11:33:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESyty-0000Qh-RP; Fri, 21 Oct 2005 11:33:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESytx-0000M2-Ng for ecrit@megatron.ietf.org; Fri, 21 Oct 2005 11:33:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10137 for ; Fri, 21 Oct 2005 11:33:37 -0400 (EDT) Received: from bay106-dav22.bay106.hotmail.com ([65.54.161.94] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESz64-0001GS-Ma for ecrit@ietf.org; Fri, 21 Oct 2005 11:46:24 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 21 Oct 2005 08:33:35 -0700 Message-ID: Received: from 12.178.162.5 by BAY106-DAV22.phx.gbl with DAV; Fri, 21 Oct 2005 15:33:34 +0000 X-Originating-IP: [12.178.162.5] X-Originating-Email: [timothydunn01@msn.com] X-Sender: timothydunn01@msn.com From: "Tim Dunn" To: "'Henning Schulzrinne'" Subject: RE: [ECRIT]: Caller Identity requirements: replacement text foremptysection in ECRIT req doc. Date: Fri, 21 Oct 2005 09:33:33 -0600 Message-ID: <004901c5d654$cc714760$1f071e0a@TimDunn> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: AAAAAHid4H6cLVBKvI35MTImwgAHANlTnCJhprtFudq2LHCBs8EBACIA//8AANlTnCJhprtFudq2LHCBs8EBAKkrAAAAAA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXWQ5uABYQ4lLVARZWkNtBRWuEAOAAEF4zQ X-OriginalArrivalTime: 21 Oct 2005 15:33:35.0927 (UTC) FILETIME=[CD436470:01C5D654] X-Spam-Score: 1.6 (+) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org That's all I believe the proposed requirement was stating, and the very direct point I've been attempting to make: Location and callback must be provided in the call process somewhere. My question is where? Why not here? (And I disagree that it is out of scope for ECRIT based on my earlier arguments). Tim -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Friday, October 21, 2005 7:25 AM To: Tim DUNN Cc: ecrit@ietf.org Subject: Re: [ECRIT]: Caller Identity requirements: replacement text foremptysection in ECRIT req doc. Tim DUNN wrote: > The PSAP needs is a location and a call back. Not providing both is a > reduction in existing capabilities in place for circuit switched and > mobile 911 calls. Both need to be accounted for somewhere in this > overall set of requirements/architecture. > It's pretty simple: The call setup request reaching the PSAP provides call back information and location information, in-band. I agree with the need for an architecture document; I've written (long-expired) versions of something approximating those. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 21 14:33:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET1iD-0006N5-7l; Fri, 21 Oct 2005 14:33:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET1iC-0006Mx-As for ecrit@megatron.ietf.org; Fri, 21 Oct 2005 14:33:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24237 for ; Fri, 21 Oct 2005 14:33:41 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET1uK-0000yI-Qs for ecrit@ietf.org; Fri, 21 Oct 2005 14:46:28 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id for ; Fri, 21 Oct 2005 14:33:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Terminology section - directory/directory svc. Date: Fri, 21 Oct 2005 11:33:27 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657503645F1D@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Terminology section - directory/directory svc. Thread-Index: AcWcwwryHcNyexfAREOj8pOahjOUTg5qd3wA From: "Roger Marshall" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org All: I noticed that in the current requirements draft, there is a reference to "directory" within the basic actors, (section 3). Since there was no definition for this term in the Terminology section, I have changed the term to "Directory Service", and have supplied the following text in hopes that it matches current thought: Directory Service: A network service which uses a distributed=20 directory protocol to provide information about the PSAP,=20 or intermediary which knows about the PSAP, and is used=20 to assist in routing an emergency call. The security draft makes a reference to "directory" pointing to this doc, so I want something listed here as a basis. Comments welcome. Roger Marshall. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 21 15:58:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET32B-00083n-6r; Fri, 21 Oct 2005 15:58:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET329-00083W-5s for ecrit@megatron.ietf.org; Fri, 21 Oct 2005 15:58:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02682 for ; Fri, 21 Oct 2005 15:58:22 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET3EK-0005c5-Qw for ecrit@ietf.org; Fri, 21 Oct 2005 16:11:10 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j9LJwL2Q010181 for ; Fri, 21 Oct 2005 21:58:22 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j9LJwLNM000627 for ; Fri, 21 Oct 2005 21:58:21 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 21 Oct 2005 21:58:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Oct 2005 21:58:21 +0200 Message-ID: Thread-Topic: Updated Draft: "Requirements for Emergency Context Resolution with Internet Technologies" Thread-Index: AcWwCEKrM4MUIyKTTFiUAxrYLOVj3gmbXrkwAAB2kgA= From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 21 Oct 2005 19:58:21.0722 (UTC) FILETIME=[C9EF57A0:01C5D679] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] WG: Updated Draft: "Requirements for Emergency Context Resolution with Internet Technologies" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org fyi,=20 please find the updated requirements draft at:=20 http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements-01.txt ciao hannes ----------------- Title:=20 Requirements for Emergency Context Resolution with Internet=20 Technologies Abstract=20 This document enumerates requirements for emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end-to-end. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 21 17:15:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET4EF-0002Ce-5W; Fri, 21 Oct 2005 17:15:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET4ED-0002CQ-Hq for ecrit@megatron.ietf.org; Fri, 21 Oct 2005 17:15:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14771 for ; Fri, 21 Oct 2005 17:14:54 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET4QP-00058u-Uw for ecrit@ietf.org; Fri, 21 Oct 2005 17:27:43 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j9LLEvWk013090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 Oct 2005 17:14:59 -0400 (EDT) Message-ID: <43595A17.1020004@cs.columbia.edu> Date: Fri, 21 Oct 2005 17:13:59 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roger Marshall Subject: Re: [Ecrit] Terminology section - directory/directory svc. References: <8C837214C95C864C9F34F3635C2A657503645F1D@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A657503645F1D@SEA-EXCHVS-2.telecomsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org How does this differ from the mapping service? Roger Marshall wrote: > All: > I noticed that in the current requirements draft, there is a reference > to "directory" within the basic actors, (section 3). Since there was no > definition for this term in the Terminology section, I have changed the > term to "Directory Service", and have supplied the following text in > hopes that it matches current thought: > > Directory Service: A network service which uses a distributed > directory protocol to provide information about the PSAP, > or intermediary which knows about the PSAP, and is used > to assist in routing an emergency call. > > The security draft makes a reference to "directory" pointing to this > doc, so I want something listed here as a basis. > > Comments welcome. > > Roger Marshall. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 21 17:24:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET4N7-0002nT-0o; Fri, 21 Oct 2005 17:24:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET4N6-0002j5-0l for ecrit@megatron.ietf.org; Fri, 21 Oct 2005 17:24:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18639 for ; Fri, 21 Oct 2005 17:24:04 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET4ZI-0006f5-G8 for ecrit@ietf.org; Fri, 21 Oct 2005 17:36:53 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Fri, 21 Oct 2005 17:23:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Terminology section - directory/directory svc. Date: Fri, 21 Oct 2005 14:23:56 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657503646154@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Terminology section - directory/directory svc. Thread-Index: AcXWhIL7bY77WrLrSpiN1JFzl7bmkAAAB8ww From: "Roger Marshall" To: "Henning Schulzrinne" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I guess I don't see a difference. Didn't know if anyone had a super-significant reason for the term "directory". The only real difference I see is between a "server" as opposed to a "service". I.E. "mapping service", a (distributed?) network service which is comprised of one or more mapping servers, and which utilizes the mapping protocol to exchange data. Roger. >-----Original Message----- >From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 >Sent: Friday, October 21, 2005 2:14 PM >To: Roger Marshall >Cc: ecrit@ietf.org >Subject: Re: [Ecrit] Terminology section - directory/directory svc. > >How does this differ from the mapping service? > >Roger Marshall wrote: >> All: >> I noticed that in the current requirements draft, there is a=20 >reference=20 >> to "directory" within the basic actors, (section 3). Since=20 >there was=20 >> no definition for this term in the Terminology section, I=20 >have changed=20 >> the term to "Directory Service", and have supplied the=20 >following text=20 >> in hopes that it matches current thought: >>=20 >> Directory Service: A network service which uses a distributed=20 >> directory protocol to provide information about the PSAP, or=20 >> intermediary which knows about the PSAP, and is used to assist in=20 >> routing an emergency call. >>=20 >> The security draft makes a reference to "directory" pointing to this=20 >> doc, so I want something listed here as a basis. >>=20 >> Comments welcome. >>=20 >> Roger Marshall. >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 21 17:33:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET4W3-00029K-NQ; Fri, 21 Oct 2005 17:33:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET4W2-00029F-OJ for ecrit@megatron.ietf.org; Fri, 21 Oct 2005 17:33:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19133 for ; Fri, 21 Oct 2005 17:33:19 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET4iF-0006zk-J1 for ecrit@ietf.org; Fri, 21 Oct 2005 17:46:08 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j9LLXQWk014244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 Oct 2005 17:33:27 -0400 (EDT) Message-ID: <43595E6B.6060606@cs.columbia.edu> Date: Fri, 21 Oct 2005 17:32:27 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roger Marshall Subject: Re: [Ecrit] Terminology section - directory/directory svc. References: <8C837214C95C864C9F34F3635C2A657503646154@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A657503646154@SEA-EXCHVS-2.telecomsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Roger Marshall wrote: > I guess I don't see a difference. Didn't know if anyone had a > super-significant reason for the term "directory". Given that the term directory probably elicits recollections of X.500, LDAP and "411" in many people, I'd avoid the term. I would thus drop references to "directory". Mapping, since we're talking about geographic regions as well as a 'mapping' between two different data items, seems sufficient. > > The only real difference I see is between a "server" as opposed to a > "service". > > I.E. "mapping service", a (distributed?) network service which is > comprised of one or more mapping servers, and which utilizes the mapping > protocol to exchange data. That distinction makes sense to me. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 21 17:36:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET4Z5-0005yf-8R; Fri, 21 Oct 2005 17:36:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET4Z3-0005u2-VD for ecrit@megatron.ietf.org; Fri, 21 Oct 2005 17:36:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19350 for ; Fri, 21 Oct 2005 17:36:26 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET4lG-00077Y-JE for ecrit@ietf.org; Fri, 21 Oct 2005 17:49:16 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Fri, 21 Oct 2005 17:36:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Terminology section - directory/directory svc. Date: Fri, 21 Oct 2005 14:36:25 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65750364618D@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Terminology section - directory/directory svc. Thread-Index: AcXWhxWWmiIwJlMJQfKVmHp5acyuMQAAD2Zg From: "Roger Marshall" To: "Henning Schulzrinne" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Agreed. Will make the change to the next version.=20 >-----Original Message----- >From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 >Sent: Friday, October 21, 2005 2:32 PM >To: Roger Marshall >Cc: ecrit@ietf.org >Subject: Re: [Ecrit] Terminology section - directory/directory svc. > > > >Roger Marshall wrote: >> I guess I don't see a difference. Didn't know if anyone had a=20 >> super-significant reason for the term "directory". > >Given that the term directory probably elicits recollections=20 >of X.500, LDAP and "411" in many people, I'd avoid the term. > >I would thus drop references to "directory". Mapping, since=20 >we're talking about geographic regions as well as a 'mapping'=20 >between two different data items, seems sufficient. > >>=20 >> The only real difference I see is between a "server" as opposed to a=20 >> "service". > > > >>=20 >> I.E. "mapping service", a (distributed?) network service which is=20 >> comprised of one or more mapping servers, and which utilizes the=20 >> mapping protocol to exchange data. > >That distinction makes sense to me. > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 21 18:31:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET5QR-0001yD-DR; Fri, 21 Oct 2005 18:31:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET5QO-0001wf-VY for ecrit@megatron.ietf.org; Fri, 21 Oct 2005 18:31:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22461 for ; Fri, 21 Oct 2005 18:31:32 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ET5cb-0000bK-RF for ecrit@ietf.org; Fri, 21 Oct 2005 18:44:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] WG: Updated Draft: "Requirements for Emergency ContextResolution with Internet Technologies" Date: Sat, 22 Oct 2005 00:34:58 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C461E@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] WG: Updated Draft: "Requirements for Emergency ContextResolution with Internet Technologies" Thread-Index: AcWwCEKrM4MUIyKTTFiUAxrYLOVj3gmbXrkwAAB2kgAABaMEOQ== From: "Stastny Richard" To: "Tschofenig, Hannes" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi all, =20 since I was off-list for some time, I tried to read the draft like a = newcomer ;-) =20 Basically I consider the draft an excellent piece of work. I will try to = sync with the discussion on the list and come back with more substantial remarks = later (hopefully before Vancouver). =20 quick comments: One issue I detected was, that I had some problem in understanding the = definition of the ESRP and map it to the Figure 1 framework. On the other hand, the term Emergency Call Routing Support is missing in = the definitions.=20 In the decription of the framework interaction (8) from figure 1 is = missing. Id3 conatins a non existing ref to A1a and A4+ Richard Stastny =20 ________________________________ Von: ecrit-bounces@ietf.org im Auftrag von Tschofenig, Hannes Gesendet: Fr 21.10.2005 21:58 An: ecrit@ietf.org Betreff: [Ecrit] WG: Updated Draft: "Requirements for Emergency = ContextResolution with Internet Technologies" fyi, please find the updated requirements draft at: http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements-01.txt ciao hannes ----------------- Title: Requirements for Emergency Context Resolution with Internet Technologies Abstract This document enumerates requirements for emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end-to-end. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Oct 22 09:13:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETJBc-0007nz-Mm; Sat, 22 Oct 2005 09:13:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETJAY-0007Dx-0Q for ecrit@megatron.ietf.org; Sat, 22 Oct 2005 09:12:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10825 for ; Sat, 22 Oct 2005 09:12:07 -0400 (EDT) Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETJMs-00077f-TG for ecrit@ietf.org; Sat, 22 Oct 2005 09:25:04 -0400 Received: from [10.0.1.103] ([::ffff:64.83.8.179]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Sat, 22 Oct 2005 09:11:51 -0400 id 0158801F.435A3A97.000018C5 In-Reply-To: <43595E6B.6060606@cs.columbia.edu> References: <8C837214C95C864C9F34F3635C2A657503646154@SEA-EXCHVS-2.telecomsys.com> <43595E6B.6060606@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <832EC831-3D2F-4DD0-B200-7BD7AF2AF381@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Terminology section - directory/directory svc. Date: Sat, 22 Oct 2005 09:11:58 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Oct 21, 2005, at 5:32 PM, Henning Schulzrinne wrote: > Given that the term directory probably elicits recollections of X. > 500, LDAP and "411" in many people, I'd avoid the term. I agree. > I would thus drop references to "directory". Mapping, since we're > talking about geographic regions as well as a 'mapping' between two > different data items, seems sufficient. It is a mapping service. Why not use the LCMS term? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 24 03:50:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETx6b-0002mg-BB; Mon, 24 Oct 2005 03:50:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETx6a-0002ma-Ag for ecrit@megatron.ietf.org; Mon, 24 Oct 2005 03:50:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22991 for ; Mon, 24 Oct 2005 03:50:38 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETxJH-0000o6-IA for ecrit@ietf.org; Mon, 24 Oct 2005 04:04:01 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j9O7oedK004831 for ; Mon, 24 Oct 2005 09:50:40 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j9O7oZvT030095 for ; Mon, 24 Oct 2005 09:50:40 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 24 Oct 2005 09:50:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Oct 2005 09:50:35 +0200 Message-ID: Thread-Topic: draft-polk-newton-ecrit-arch-considerations-01 Thread-Index: AcXYQ1n1i5uVuz1jS8epGA4rXYv1lgAKxW9g From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 24 Oct 2005 07:50:36.0587 (UTC) FILETIME=[9EB9BFB0:01C5D86F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] WG: draft-polk-newton-ecrit-arch-considerations-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all,=20 james and andy produced an update of the draft.=20 please find it at http://www.ietf-ecrit.org/cache/draft-polk-newton-ecrit-arch-considerati ons-01.txt.=20 ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 24 16:37:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU94E-000870-QM; Mon, 24 Oct 2005 16:37:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU94D-00085Y-6B for ecrit@megatron.ietf.org; Mon, 24 Oct 2005 16:37:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17846 for ; Mon, 24 Oct 2005 16:36:58 -0400 (EDT) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU9Gy-0006i8-6S for ecrit@ietf.org; Mon, 24 Oct 2005 16:50:27 -0400 Received: from ZTCFHXM0.corp.nortel.com (ztcfhxm0.corp.nortel.com [47.10.33.94]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9OKamL06274; Mon, 24 Oct 2005 16:36:48 -0400 (EDT) Received: from zcarhxs1.corp.nortel.com ([47.129.230.89]) by ZTCFHXM0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Oct 2005 16:36:46 -0400 Received: from [127.0.0.1] ([47.130.16.87] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Oct 2005 16:36:45 -0400 Message-ID: <435D45D9.3060108@nortel.com> Date: Mon, 24 Oct 2005 16:36:41 -0400 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim DUNN Subject: Re: [ECRIT]: Caller Identity requirements: replacement text foremptysection in ECRIT req doc. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Oct 2005 20:36:45.0857 (UTC) FILETIME=[A68BB110:01C5D8DA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think you're under the mistaken impression that ECRIT is producing a complete solution to emergency service calling. That simply isn't so. The complete solution has to be worked in bodies that create architectures and not just protocols. Tim DUNN wrote: > The PSAP needs is a location and a call back. Not providing both is a > reduction in existing capabilities in place for circuit switched and > mobile 911 calls. Both need to be accounted for somewhere in this > overall set of requirements/architecture. > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 24 18:58:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUBGw-0006Wy-HA; Mon, 24 Oct 2005 18:58:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU8Kc-0002u3-Op; Mon, 24 Oct 2005 15:50:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28583; Mon, 24 Oct 2005 15:49:51 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU8XN-0007ce-VI; Mon, 24 Oct 2005 16:03:19 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EU8KY-0002FM-H2; Mon, 24 Oct 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 24 Oct 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 X-Mailman-Approved-At: Mon, 24 Oct 2005 18:58:29 -0400 Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-requirements-01.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Requirements for Emergency Context Resolution with Internet Technologies Author(s) : H. Schulzrinne, R. Marshall Filename : draft-ietf-ecrit-requirements-01.txt Pages : 25 Date : 2005-10-24 This document enumerates requirements for emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end-to-end. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ecrit-requirements-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ecrit-requirements-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-24131515.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-requirements-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-requirements-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-24131515.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --NextPart-- From ecrit-bounces@ietf.org Tue Oct 25 05:43:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EULLW-0002Z8-F1; Tue, 25 Oct 2005 05:43:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EULLV-0002Z3-2i for ecrit@megatron.ietf.org; Tue, 25 Oct 2005 05:43:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03301 for ; Tue, 25 Oct 2005 05:43:37 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EULYP-0004NU-Nk for ecrit@ietf.org; Tue, 25 Oct 2005 05:57:15 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j9P9hfnT031504 for ; Tue, 25 Oct 2005 11:43:41 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j9P9hd7P004331 for ; Tue, 25 Oct 2005 11:43:40 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 25 Oct 2005 11:43:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Oct 2005 11:43:12 +0200 Message-ID: Thread-Topic: draft-hardie-ecrit-iris-03.txt Thread-Index: AcXWaWYYAfjGvGi6T9+4F9rdEyayVgC3ilrQ From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 25 Oct 2005 09:43:27.0014 (UTC) FILETIME=[8CA0AC60:01C5D948] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] WG: draft-hardie-ecrit-iris-03.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all,=20 andy has submitted a new draft version of the 'An IRIS schema for Emergency Service contact URIs' document.=20 please find it at:=20 http://www.ietf-ecrit.org/cache/draft-hardie-ecrit-iris-03.txt the changes include: - simplified service types in section 3.2 and=20 - improved description of the deployment scenarios in section 2.4 ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 25 16:25:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUVMl-0001IJ-Sx; Tue, 25 Oct 2005 16:25:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUVMj-00019A-NC for ecrit@megatron.ietf.org; Tue, 25 Oct 2005 16:25:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28070 for ; Tue, 25 Oct 2005 16:25:33 -0400 (EDT) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUVZj-00045C-1j for ecrit@ietf.org; Tue, 25 Oct 2005 16:39:16 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1EUVMJ-00085a-Fx for ecrit@ietf.org; Tue, 25 Oct 2005 15:25:24 -0500 From: "Brian Rosen" To: Date: Tue, 25 Oct 2005 16:24:38 -0400 Message-ID: <03fe01c5d9a2$21533e00$74201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXZoh9qHdzvKGSGTjmVlrfZSS2/xg== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.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 Subject: [Ecrit] New version of dns-sos draft available X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I have updated the dns-sos draft. Until it is announced, you can find it at: http://www.brianrosen.net/internet-drafts/draft-rosen-dns-sos-03.txt http://www.brianrosen.net/internet-drafts/draft-rosen-dns-sos-03.html http://www.brianrosen.net/internet-drafts/draft-rosen-dns-sos-03.xml This version includes text on how geo based mapping is accomplished. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 25 20:19:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUZ0Q-0002YB-1U; Tue, 25 Oct 2005 20:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUZ0O-0002V1-RR for ecrit@megatron.ietf.org; Tue, 25 Oct 2005 20:19:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08930 for ; Tue, 25 Oct 2005 20:18:46 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUZDR-0003zG-Gm for ecrit@ietf.org; Tue, 25 Oct 2005 20:32:30 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j9Q0IuWk020359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 25 Oct 2005 20:18:57 -0400 (EDT) Message-ID: <435ECB2C.3040409@cs.columbia.edu> Date: Tue, 25 Oct 2005 20:17:48 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'ecrit@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Subject: [Ecrit] LUMP and mapping architecture documents X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org http://www.cs.columbia.edu/sip/draft/lump-arch/draft-schulzrinne-ecrit-mapping-arch-00.html describes an overall architecture that allows fully distributed mapping. It is relatively protocol-agnostic, although it clearly wouldn't work (or be needed) for a DNS-based solution. In its simplest incarnation, it consists of a single server, but I was trying to come up with something that can scale to global deployment. It separates the problem into four roles (queriers, authoritative servers, forest guides and resolvers), each with a distinct set of responsibilities, even though the number of protocol operations is not as large. The split was motivated by my desire to allow for a system that is operated by a variety of parties and requiring minimal cooperation and turf fights. (I think that's one of the strengths of the DNS, for example, except for the "who owns the root" fight breaking out between Oceania and Eurasia.) The protocol pieces are now in http://www.cs.columbia.edu/sip/draft/lump/draft-schulzrinne-ecrit-lump-01.html This is essentially just a commented WSDL and XML schema description, with two requests, to get a mapping and to get a region. This covers some of the interfaces described in the architecture document and is sufficient for the querier-resolver or resolver-authoritative server component, but not for the inter-forest-guide protocol machinery. This is not yet complete, but eventually, one should be able to automatically generate the protocol machinery from the WSDL file, e.g., using the GLUE, WebSphere or Apache AXIS server (or .NET). I've only described a SOAP binding in the document, but any web services binding would work, including (but not very usefully...) email and, more usefully, a simple REST-style HTTP GET operation. Comments would be particularly appreciated. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 25 20:25:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUZ6q-00086r-D6; Tue, 25 Oct 2005 20:25:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUZ6o-00085n-4l for ecrit@megatron.ietf.org; Tue, 25 Oct 2005 20:25:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09246 for ; Tue, 25 Oct 2005 20:25:23 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUZJq-0004AX-Tz for ecrit@ietf.org; Tue, 25 Oct 2005 20:39:08 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j9Q0PXWk020861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 25 Oct 2005 20:25:34 -0400 (EDT) Message-ID: <435ECCBA.2010203@cs.columbia.edu> Date: Tue, 25 Oct 2005 20:24:26 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Subject: [Ecrit] SOS and service URN drafts X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I have re-submitted slightly changed versions of older drafts: http://www.cs.columbia.edu/sip/draft/sos/draft-ietf-sipping-sos-01.html is a somewhat updated version of the long-expired 'SOS' draft that's been ghosting around the I-D archives for a while. Besides updating some references, I've trimmed material that no longer seemed to belong there. It still references an architecture draft, which would need a major overhaul or (more likely) be dropped from the reference list, but I believe it is otherwise complete. Section 5 may belong into sinnreich-sipdev-req or the oft-cited "BCP" instead. http://www.cs.columbia.edu/sip/draft/service/draft-schulzrinne-sipping-service-01.html is a minor keep-alive editorial update of the service URN draft. If possible, I'd like to discuss both in Vancouver, so that I some idea whether to pursue zero, one or both of these proposals further. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 25 20:36:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUZHF-0005DX-Be; Tue, 25 Oct 2005 20:36:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUZHD-0005DL-9h for ecrit@megatron.ietf.org; Tue, 25 Oct 2005 20:36:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09652 for ; Tue, 25 Oct 2005 20:36:08 -0400 (EDT) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUZUG-0004O9-2Z for ecrit@ietf.org; Tue, 25 Oct 2005 20:49:53 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 19:36:08 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Tue, 25 Oct 2005 19:36:07 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 19:35:28 -0500 Message-ID: From: "Winterbottom, James" To: "Henning Schulzrinne" , Date: Tue, 25 Oct 2005 19:36:05 -0500 Subject: RE: [Ecrit] LUMP and mapping architecture documents MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 26 Oct 2005 00:35:28.0358 (UTC) FILETIME=[29D5A860:01C5D9C5] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] LUMP and mapping architecture documents Thread-Index: AcXZwvYiZU6s95ojRz2byD2CVIHC+gAAJhxw X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Henning, I will have more comments on this draft later. But for now there is a clear mistake in the XML in that your geo option is using a type of "ca:civicAddress" *8) Cheers James=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Henning Schulzrinne > Sent: Wednesday, 26 October 2005 10:18 AM > To: 'ecrit@ietf.org' > Subject: [Ecrit] LUMP and mapping architecture documents >=20 > http://www.cs.columbia.edu/sip/draft/lump-arch/draft-schulzrinne-ecrit- > mapping-arch-00.html >=20 > describes an overall architecture that allows fully distributed mapping. > It is relatively protocol-agnostic, although it clearly wouldn't work > (or be needed) for a DNS-based solution. In its simplest incarnation, it > consists of a single server, but I was trying to come up with something > that can scale to global deployment. It separates the problem into four > roles (queriers, authoritative servers, forest guides and resolvers), > each with a distinct set of responsibilities, even though the number of > protocol operations is not as large. The split was motivated by my > desire to allow for a system that is operated by a variety of parties > and requiring minimal cooperation and turf fights. (I think that's one > of the strengths of the DNS, for example, except for the "who owns the > root" fight breaking out between Oceania and Eurasia.) >=20 > The protocol pieces are now in >=20 > http://www.cs.columbia.edu/sip/draft/lump/draft-schulzrinne-ecrit-lump- > 01.html >=20 > This is essentially just a commented WSDL and XML schema description, > with two requests, to get a mapping and to get a region. This covers > some of the interfaces described in the architecture document and is > sufficient for the querier-resolver or resolver-authoritative server > component, but not for the inter-forest-guide protocol machinery. >=20 > This is not yet complete, but eventually, one should be able to > automatically generate the protocol machinery from the WSDL file, e.g., > using the GLUE, WebSphere or Apache AXIS server (or .NET). >=20 > I've only described a SOAP binding in the document, but any web services > binding would work, including (but not very usefully...) email and, more > usefully, a simple REST-style HTTP GET operation. >=20 > Comments would be particularly appreciated. >=20 >=20 > Henning >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 25 21:39:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUaFq-0007OA-Ru; Tue, 25 Oct 2005 21:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUaFo-0007Nx-TH for ecrit@megatron.ietf.org; Tue, 25 Oct 2005 21:39:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12471 for ; Tue, 25 Oct 2005 21:38:43 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUaSp-0005sd-UF for ecrit@ietf.org; Tue, 25 Oct 2005 21:52:29 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j9Q1crWk024721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Oct 2005 21:38:54 -0400 (EDT) Message-ID: <435EDDE9.6050601@cs.columbia.edu> Date: Tue, 25 Oct 2005 21:37:45 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Winterbottom, James" , ecrit@ietf.org Subject: Re: [Ecrit] LUMP and mapping architecture documents References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Thanks - yes, the dangers of relying too much on XMLspy rather than validation by human inspection :-) More seriously: What would be the appropriate XML object for geo only? gml:position? Thanks. Henning Winterbottom, James wrote: > Hi Henning, > > I will have more comments on this draft later. > But for now there is a clear mistake in the XML in that your geo option > is using a type of "ca:civicAddress" > > *8) > > Cheers > James > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 25 21:43:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUaJm-0002FD-9J; Tue, 25 Oct 2005 21:43:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUaJk-0002F3-FG for ecrit@megatron.ietf.org; Tue, 25 Oct 2005 21:43:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12699 for ; Tue, 25 Oct 2005 21:42:49 -0400 (EDT) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUaWn-00060d-US for ecrit@ietf.org; Tue, 25 Oct 2005 21:56:35 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 20:42:54 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Tue, 25 Oct 2005 20:42:53 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 20:42:52 -0500 Message-ID: From: "Thomson, Martin" To: "Henning Schulzrinne" , "Winterbottom, James" , Date: Tue, 25 Oct 2005 20:41:56 -0500 Subject: RE: [Ecrit] LUMP and mapping architecture documents MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 26 Oct 2005 01:42:52.0850 (UTC) FILETIME=[948A2920:01C5D9CE] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] LUMP and mapping architecture documents Thread-Index: AcXZzjqZdaKMIsmIRRaw1RvUybYHOQAABE6Q X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1168653014==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --===============1168653014== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message Content-Transfer-Encoding: base64 SSBjYW4gYW5zd2VyIHRoYXQgb25lLg0KDQpnbWw6X0ZlYXR1cmUgaXMgdGhlIGNvcnJlY3Qgb2Jq ZWN0LCBiYXNlZCBvbiB0aGUgUElERi1MTyBzcGVjLiAgVGhpcyBlbGVtZW50IGlzIHRoZSBhYnN0 cmFjdCBoZWFkIG9mIGEgc3Vic3RpdHV0aW9uIGdyb3VwIHRoYXQgaW5jbHVkZXMgZ21sOnBvc2l0 aW9uLg0KDQpDaGVlcnMsDQpNYXJ0aW4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgSGVubmluZyBTY2h1bHpyaW5uZQ0KU2VudDogV2VkbmVzZGF5LCAyNiBP Y3RvYmVyIDIwMDUgMTE6MzggQU0NClRvOiBXaW50ZXJib3R0b20sIEphbWVzOyBlY3JpdEBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtFY3JpdF0gTFVNUCBhbmQgbWFwcGluZyBhcmNoaXRlY3R1cmUg ZG9jdW1lbnRzDQoNClRoYW5rcyAtIHllcywgdGhlIGRhbmdlcnMgb2YgcmVseWluZyB0b28gbXVj aCBvbiBYTUxzcHkgcmF0aGVyIHRoYW4gDQp2YWxpZGF0aW9uIGJ5IGh1bWFuIGluc3BlY3Rpb24g Oi0pDQoNCk1vcmUgc2VyaW91c2x5OiBXaGF0IHdvdWxkIGJlIHRoZSBhcHByb3ByaWF0ZSBYTUwg b2JqZWN0IGZvciBnZW8gb25seT8gDQpnbWw6cG9zaXRpb24/DQoNClRoYW5rcy4NCg0KSGVubmlu Zw0KDQpXaW50ZXJib3R0b20sIEphbWVzIHdyb3RlOg0KPiBIaSBIZW5uaW5nLA0KPiANCj4gSSB3 aWxsIGhhdmUgbW9yZSBjb21tZW50cyBvbiB0aGlzIGRyYWZ0IGxhdGVyLg0KPiBCdXQgZm9yIG5v dyB0aGVyZSBpcyBhIGNsZWFyIG1pc3Rha2UgaW4gdGhlIFhNTCBpbiB0aGF0IHlvdXIgZ2VvIG9w dGlvbg0KPiBpcyB1c2luZyBhIHR5cGUgb2YgImNhOmNpdmljQWRkcmVzcyINCj4gDQo+ICo4KQ0K PiANCj4gQ2hlZXJzDQo+IEphbWVzIA0KPiANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCkVjcml0IG1haWxpbmcgbGlzdA0KRWNyaXRAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUg ZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQpjb250YWluIHByaXZpbGVnZWQsIHBy b3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4gIA0KSWYgeW91IGhh dmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KaW1tZWRp YXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0K dGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpbbWYyXQ== --===============1168653014== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1168653014==-- From ecrit-bounces@ietf.org Tue Oct 25 21:44:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUaKg-0002aJ-ME; Tue, 25 Oct 2005 21:44:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUaKf-0002a9-6k for ecrit@megatron.ietf.org; Tue, 25 Oct 2005 21:44:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12727 for ; Tue, 25 Oct 2005 21:43:46 -0400 (EDT) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUaXi-00061v-Ly for ecrit@ietf.org; Tue, 25 Oct 2005 21:57:31 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 20:43:51 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Tue, 25 Oct 2005 20:43:50 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 20:43:07 -0500 Message-ID: From: "Winterbottom, James" To: "Thomson, Martin" , "Henning Schulzrinne" , Date: Tue, 25 Oct 2005 20:43:48 -0500 Subject: RE: [Ecrit] LUMP and mapping architecture documents MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 26 Oct 2005 01:43:07.0790 (UTC) FILETIME=[9D71D2E0:01C5D9CE] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] LUMP and mapping architecture documents Thread-Index: AcXZzjqZdaKMIsmIRRaw1RvUybYHOQAABE6QAAAVnvA= X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think that I would also make reference to the PIDF-LO profile document recommended representations. > -----Original Message----- > From: Thomson, Martin > Sent: Wednesday, 26 October 2005 11:42 AM > To: Henning Schulzrinne; Winterbottom, James; ecrit@ietf.org > Subject: RE: [Ecrit] LUMP and mapping architecture documents >=20 > I can answer that one. >=20 > gml:_Feature is the correct object, based on the PIDF-LO spec. This > element is the abstract head of a substitution group that includes > gml:position. >=20 > Cheers, > Martin >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Henning Schulzrinne > Sent: Wednesday, 26 October 2005 11:38 AM > To: Winterbottom, James; ecrit@ietf.org > Subject: Re: [Ecrit] LUMP and mapping architecture documents >=20 > Thanks - yes, the dangers of relying too much on XMLspy rather than > validation by human inspection :-) >=20 > More seriously: What would be the appropriate XML object for geo only? > gml:position? >=20 > Thanks. >=20 > Henning >=20 > Winterbottom, James wrote: > > Hi Henning, > > > > I will have more comments on this draft later. > > But for now there is a clear mistake in the XML in that your geo option > > is using a type of "ca:civicAddress" > > > > *8) > > > > Cheers > > James > > >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 26 04:46:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUgv2-0000lz-EY; Wed, 26 Oct 2005 04:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUgv1-0000lt-0h for ecrit@megatron.ietf.org; Wed, 26 Oct 2005 04:45:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04565 for ; Wed, 26 Oct 2005 04:45:43 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUh87-0001Qr-Uy for ecrit@ietf.org; Wed, 26 Oct 2005 04:59:33 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j9Q8jWJH013736; Wed, 26 Oct 2005 10:45:32 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j9Q8jUJ3029632; Wed, 26 Oct 2005 10:45:32 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 26 Oct 2005 10:45:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] SOS and service URN drafts Date: Wed, 26 Oct 2005 10:45:28 +0200 Message-ID: Thread-Topic: [Ecrit] SOS and service URN drafts Thread-Index: AcXZw+VHXvRvsC3lTYe7gVWKRYNq9QAQd1hA From: "Tschofenig, Hannes" To: "Henning Schulzrinne" , X-OriginalArrivalTime: 26 Oct 2005 08:45:28.0493 (UTC) FILETIME=[9DAE3DD0:01C5DA09] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi henning,=20 thanks for the draft update. these documents are important for our work = and we also have an charter item about it: " Aug 05 A BCP describing how to identify a session set-up request is = to an emergency response center =20 " the question therefore is only: do we only need one or both (and how do = they relate to each other)?=20 additionally, we need to clarify where the work has to be done - ecrit = or sipping. but that's probably the least important question.=20 ciao hannes > -----Urspr=FCngliche Nachricht----- > Von: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > Im Auftrag von Henning Schulzrinne > Gesendet: Mittwoch, 26. Oktober 2005 02:24 > An: ecrit@ietf.org > Betreff: [Ecrit] SOS and service URN drafts >=20 >=20 > I have re-submitted slightly changed versions of older drafts: >=20 > http://www.cs.columbia.edu/sip/draft/sos/draft-ietf-sipping-so s-01.html is a somewhat updated version of the long-expired 'SOS' draft that's=20 been ghosting around the I-D archives for a while. Besides updating some = references, I've trimmed material that no longer seemed to belong there. = It still references an architecture draft, which would need a major=20 overhaul or (more likely) be dropped from the reference list, but I=20 believe it is otherwise complete. Section 5 may belong into=20 sinnreich-sipdev-req or the oft-cited "BCP" instead. http://www.cs.columbia.edu/sip/draft/service/draft-schulzrinne-sipping-se= rvice-01.html is a minor keep-alive editorial update of the service URN draft. If possible, I'd like to discuss both in Vancouver, so that I some idea=20 whether to pursue zero, one or both of these proposals further. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 26 09:33:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUlPX-0002iJ-OQ; Wed, 26 Oct 2005 09:33:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUlPW-0002iE-8d for ecrit@megatron.ietf.org; Wed, 26 Oct 2005 09:33:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19680 for ; Wed, 26 Oct 2005 09:33:31 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUlcf-0001jL-UO for ecrit@ietf.org; Wed, 26 Oct 2005 09:47:23 -0400 Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net [141.153.174.94]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j9QDXYcL006784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 Oct 2005 09:33:39 -0400 (EDT) Message-ID: <435F85A5.5090506@cs.columbia.edu> Date: Wed, 26 Oct 2005 09:33:25 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Tschofenig, Hannes" Subject: Re: AW: [Ecrit] SOS and service URN drafts References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.2 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Tschofenig, Hannes wrote: > hi henning, > > thanks for the draft update. these documents are important for our work and we also have an charter item about it: > " > Aug 05 A BCP describing how to identify a session set-up request is to an emergency response center > " > > the question therefore is only: do we only need one or both (and how do they relate to each other)? > The 'sos' draft has a brief description of the trade-offs involved between the two solutions. Here's my slightly longer take: - "urn:service" is a long-term solution that better fits the general URN/SIP model and can be applied to other problems beyond emergency calling, but requires infrastructure upgrades throughout, from UAs to proxies and maybe other entities such as SBCs. It is protocol-independent as long as a protocol supports URLs. I think it is also the correct solution to identifying services within the mapping protocol, even if 'sip:sos@' is used in the protocol request itself. - "sip:sos" is immediately deployable and should work with just about anything out there that does SIP. It doesn't extend as nicely to other services and is obviously SIP-specific. I think the best way forward is to progress both; the additional implementation complexity is rather modest and I think there's a reasonable transition path. The only issue is that UAs that want to support the service URN would need to be able to fall back to 'sip:sos@' if their outbound proxy returns a 404. The 'sos' draft can then be labeled appropriately and refer to the 'service' draft as the longer-term solution. The 'sipdev-req' document in SIPPING can then include the appropriate wording to guide implementors. The 'sos' draft also has a brief section on other approaches that have been suggested in the past and why I believe that they are probably not as good. Thus, I'd appreciate if people who have other suggestions would consult that section so that we don't have to repeat discussions from eons ago. The caller preferences indication in the 'sos' draft is largely independent of the URL convention and thus probably should be discussed separately. (It is needed for the sip:sos draft, however, if we want to distinguish different emergency services.) As I mentioned earlier, I think both drafts are completely orthogonal to the mapping protocol and don't prejudice its evolution. We need call identification even while the "i2" solution is still being deployed. The longer we wait, the larger the likely mess. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 26 12:56:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUoaB-00006P-2K; Wed, 26 Oct 2005 12:56:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUoa7-0008UQ-Ew for ecrit@megatron.ietf.org; Wed, 26 Oct 2005 12:56:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07198 for ; Wed, 26 Oct 2005 12:56:39 -0400 (EDT) Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUonJ-0001gc-II for ecrit@ietf.org; Wed, 26 Oct 2005 13:10:33 -0400 Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Wed, 26 Oct 2005 12:56:41 -0400 id 0158802A.435FB549.00005544 In-Reply-To: <435D45D9.3060108@nortel.com> References: <435D45D9.3060108@nortel.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [ECRIT]: Caller Identity requirements: replacement text foremptysection in ECRIT req doc. Date: Wed, 26 Oct 2005 12:56:53 -0400 To: Tom-PT Taylor X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Given this message: http://www1.ietf.org/mail-archive/web/ecrit/ current/msg01077.html Perhaps the scope of ECRIT is even more restrictive in that we are not even suppose to contemplate the other pieces that make the total solution. I understand the IESG's reluctance to grant working group charters for work that seems open ended, prone to rat holes, and quite easy to drive into the weeds. But I also think it equally unwise to be so restrictive as to generate incomplete and/or unworkable solutions. -andy On Oct 24, 2005, at 4:36 PM, Tom-PT Taylor wrote: > I think you're under the mistaken impression that ECRIT is > producing a complete solution to emergency service calling. That > simply isn't so. The complete solution has to be worked in bodies > that create architectures and not just protocols. > > Tim DUNN wrote: > >> The PSAP needs is a location and a call back. Not providing both >> is a reduction in existing capabilities in place for circuit >> switched and mobile 911 calls. Both need to be accounted for >> somewhere in this overall set of requirements/architecture. >> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 26 13:59:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUpYW-00004w-SB; Wed, 26 Oct 2005 13:59:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUpYS-0008T5-Bj for ecrit@megatron.ietf.org; Wed, 26 Oct 2005 13:59:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10648 for ; Wed, 26 Oct 2005 13:58:59 -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.43) id 1EUplf-0003c6-6z for ecrit@ietf.org; Wed, 26 Oct 2005 14:12:55 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 26 Oct 2005 10:59:07 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9QHx394000383; Wed, 26 Oct 2005 10:59:04 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 10:58:55 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 10:58:54 -0700 From: "Marc Linsner" To: "'Andrew Newton'" , "'Tom-PT Taylor'" Subject: RE: [ECRIT]: Caller Identity requirements: replacementtext foremptysection in ECRIT req doc. Date: Wed, 26 Oct 2005 13:58:52 -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: AcXaTlitbq2wnCRsTBqLkrZk4/Hw3gAAb0OQ In-Reply-To: Message-ID: X-OriginalArrivalTime: 26 Oct 2005 17:58:55.0124 (UTC) FILETIME=[EE600540:01C5DA56] X-Spam-Score: 1.1 (+) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Andy, I struggling to grasp your point. Emergency Context Routing - I think the operative word is 'routing'. As Tom alluded to, ECRIT is not the end-all, be-all to an Emergency Calling Architecture. Tim Dunn is not the only one to express displeasure with this fact. Delivering caller information and location information to a PSAP is orthogonal to routing the call. ECRIT will figure out how to identify an emergency call, then how to route an emergency call. As you stated, the IESG believes that managing small tasks is a better process than tackling large tasks. I believe this mechanism is prudent as evidenced by ECRIT's slow progress to date even with such a narrow scope. Alternatively, I also believe that ECRIT would be moving faster if there was common understanding to an overall architecture, which is why Hannes and I don't want to deter such contributions along this topic, yet we must keep moving towards the chartered goals. Do you have suggestions that would better our process? Thanks, -Marc- > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Andrew Newton > Sent: Wednesday, October 26, 2005 12:57 PM > To: Tom-PT Taylor > Cc: ecrit@ietf.org > Subject: Re: [ECRIT]: Caller Identity requirements: > replacementtext foremptysection in ECRIT req doc. > > Given this message: http://www1.ietf.org/mail-archive/web/ecrit/ > current/msg01077.html > Perhaps the scope of ECRIT is even more restrictive in that > we are not even suppose to contemplate the other pieces that > make the total solution. > > I understand the IESG's reluctance to grant working group > charters for work that seems open ended, prone to rat holes, > and quite easy to drive into the weeds. But I also think it > equally unwise to be so restrictive as to generate incomplete > and/or unworkable solutions. > > -andy > > On Oct 24, 2005, at 4:36 PM, Tom-PT Taylor wrote: > > > I think you're under the mistaken impression that ECRIT is > > producing a complete solution to emergency service calling. That > > simply isn't so. The complete solution has to be worked in bodies > > that create architectures and not just protocols. > > > > Tim DUNN wrote: > > > >> The PSAP needs is a location and a call back. Not providing both > >> is a reduction in existing capabilities in place for circuit > >> switched and mobile 911 calls. Both need to be accounted for > >> somewhere in this overall set of requirements/architecture. > >> > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 26 14:30:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUq2p-0001tr-JU; Wed, 26 Oct 2005 14:30:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUq2n-0001tj-Mj for ecrit@megatron.ietf.org; Wed, 26 Oct 2005 14:30:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12926 for ; Wed, 26 Oct 2005 14:30:22 -0400 (EDT) Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUqFz-0004mD-RL for ecrit@ietf.org; Wed, 26 Oct 2005 14:44:17 -0400 Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Wed, 26 Oct 2005 14:30:14 -0400 id 01588061.435FCB36.00006F4B In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [ECRIT]: Caller Identity requirements: replacementtext foremptysection in ECRIT req doc. Date: Wed, 26 Oct 2005 14:30:27 -0400 To: Marc Linsner X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Oct 26, 2005, at 1:58 PM, Marc Linsner wrote: > Emergency Context Routing - I think the operative word is 'routing'. In the title of this working group, the operative word is "resolution". :) > Alternatively, I also believe that ECRIT would be moving faster if > there was > common understanding to an overall architecture, which is why > Hannes and I > don't want to deter such contributions along this topic, yet we > must keep > moving towards the chartered goals. I agree that we would be moving faster if there were a common understanding for the architecture. But why produce a solution before you understand the architecture? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 26 16:10:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUrbH-0006Sv-9N; Wed, 26 Oct 2005 16:10:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUrbF-0006SI-EN for ecrit@megatron.ietf.org; Wed, 26 Oct 2005 16:10:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24119 for ; Wed, 26 Oct 2005 16:09:59 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUroM-0001Kb-TX for ecrit@ietf.org; Wed, 26 Oct 2005 16:23:52 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j9QK9rOo026614; Wed, 26 Oct 2005 22:09:53 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j9QK9qnk008586; Wed, 26 Oct 2005 22:09:53 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 26 Oct 2005 22:09:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [ECRIT]: Caller Identity requirements: replacementtext foremptysection in ECRIT req doc. Date: Wed, 26 Oct 2005 22:09:51 +0200 Message-ID: Thread-Topic: [ECRIT]: Caller Identity requirements: replacementtext foremptysection in ECRIT req doc. Thread-Index: AcXaTmn6K4jG13M+RXCuMlEcZ74G2QAF6foA From: "Tschofenig, Hannes" To: "Andrew Newton" , "Tom-PT Taylor" X-OriginalArrivalTime: 26 Oct 2005 20:09:51.0879 (UTC) FILETIME=[395DB170:01C5DA69] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all,=20 a complete solution providing emergency service requires a number of = things to be in place and some of them are even outside the ietf.=20 we develop important parts of the entire solution space. i think that there is no problem with this.=20 ciao hannes > -----Urspr=FCngliche Nachricht----- > Von: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > Im Auftrag von Andrew Newton > Gesendet: Mittwoch, 26. Oktober 2005 18:57 > An: Tom-PT Taylor > Cc: ecrit@ietf.org > Betreff: Re: [ECRIT]: Caller Identity requirements:=20 > replacementtext foremptysection in ECRIT req doc. >=20 >=20 > Given this message: http://www1.ietf.org/mail-archive/web/ecrit/=20 > current/msg01077.html > Perhaps the scope of ECRIT is even more restrictive in that we are =20 > not even suppose to contemplate the other pieces that make the total =20 > solution. >=20 > I understand the IESG's reluctance to grant working group charters =20 > for work that seems open ended, prone to rat holes, and quite=20 > easy to =20 > drive into the weeds. But I also think it equally unwise to be so =20 > restrictive as to generate incomplete and/or unworkable solutions. >=20 > -andy >=20 > On Oct 24, 2005, at 4:36 PM, Tom-PT Taylor wrote: >=20 > > I think you're under the mistaken impression that ECRIT is =20 > > producing a complete solution to emergency service calling. That =20 > > simply isn't so. The complete solution has to be worked in bodies =20 > > that create architectures and not just protocols. > > > > Tim DUNN wrote: > > > >> The PSAP needs is a location and a call back. Not providing both =20 > >> is a reduction in existing capabilities in place for circuit =20 > >> switched and mobile 911 calls. Both need to be accounted for =20 > >> somewhere in this overall set of requirements/architecture. > >> > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 26 16:15:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUrg4-00028u-HL; Wed, 26 Oct 2005 16:15:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUrg2-00027w-EY for ecrit@megatron.ietf.org; Wed, 26 Oct 2005 16:15:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27084 for ; Wed, 26 Oct 2005 16:14:58 -0400 (EDT) Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUrtF-0002RC-G0 for ecrit@ietf.org; Wed, 26 Oct 2005 16:28:54 -0400 Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Wed, 26 Oct 2005 16:14:53 -0400 id 01588070.435FE3BD.0000046B Mime-Version: 1.0 (Apple Message framework v734) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ECRIT From: Andrew Newton Date: Wed, 26 Oct 2005 16:15:06 -0400 X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.2 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Content-Transfer-Encoding: 7bit Subject: [Ecrit] thoughts on draft-taylor-ecrit-security-threats-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Here are my comments on the security threats and requirements document. Overall, I like the format and structure of the document. The authors have done a good job. However, I am concerned about the security requirements from two main perspectives: a) First, I question whether or not they are overly burdensome with regard to performance. Invoking channel security is more than just a few roundtrips and is CPU intensive. Additionally, the requirement for object signing may be even more burdensome, as it requires the triple of location info, URI, and timestamp (that's a lot of data to sign -- especially in the geo x,y,z case, and just how often does it need resigning). And I certainly don't think both of these measures are required. b) There is no discussion regarding what a user would do if authentication fails. What does it mean? Do they just put down the phone and let their house burn down? Or do they continue on with the call in hopes that the authentication failure is false indicator? Anyway, here are my comments: From Section 1: > As a corollary, the present document > does not distinguish between the case where location is provided by > reference and the case where it is provided by value within session > signalling. If both location by reference and location by value are to be part of the solution, then I think the security differences between the two should be enumerated. Is this planned for a future rev, or is this analysis pending a decision on the use of location by reference? From Section 4.3.1.1 > To avoid > launching DoS, the mapping server should be capable of limiting the > queries from a single IP, especially when an anonymous mapping is > requested, at a particular time. I keyed in on the word "anonymous". Perhaps this is one of those cases where there is no agreement on the requirement, but I thought ALL mapping requests would be anonymous. As in, no user information is sent to the mapping server. From Section 4.3.2 > An adversary might run a faked mapping server aiming to pretend that > it is a legitimate server. This would lead an emergency caller to > get bogus URI(s) that hinder a caller not to avail the emergency > service. It is necessary for the client to authenticate and possibly > to authorize the mapping server as part of the emergency call > procedure. Taking the last part first, I'm not sure how a client is to authorize the use of a mapping server. This needs to be explained. With regard to authentication of the mapping server, I do not agree that this is necessary for three reasons: a) With authentication of the mapping server, I'm assume that this refers to some sort of crypto, most likely TLS. There are two implications here: there is a performance penalty for every mapping request and there is the overhead of getting client vendors and server operators to agree upon trust anchors. b) What does the usage scenario say about an improper authentication? If the mapping server does not authenticate, is the call dropped? c) There is another alternative, which is to sign the data the server gives back. From Section 4.3.2.1 > Channel Security: It is possible to establish a secure channel e.g., > TLS to ensure the authenticity of the given mapped information. > Additionally, there are several advantages in establishing a > secure channel such as confidentiality protection, replay > protection and in case if the mapping server realizes that it is > under flooding attack (query) it might also request the > certificate, if available, to verify the identity of the > requesting client. Consequently, this step might decrease the > performance of the mapping service since the certificate > processing and key exchange mechanism pose serious performance > degradation for the mapping server. I think authentication of the client with user-based certs (assigned to individuals) is unlikely to see deployment in our life times. Using vender assigned certs is a much more reasonable idea, but it suffers from the flea market problem. > Object Security: It is possible to use object security e.g., S/MIME > to sign the individual information in the query/response message > of the mapping service. This mechanism with various settings also > provides authentication, a degree of confidentiality protection of > the sender and prevents from the replay attacks. Things like S/MIME are vulnerable to replay, and therefore object security is of little benefit. Perhaps the proper term needed is transaction signing. A request is made, and the response contains a signed answer plus transaction ID (something from the request). From Section 5.4 > o The maping client MUST be able to authenticate the mapping server. Covered above. > o The mapping server MUST be provide data origin authentication > thereby ensuring that the provided data items are indeed from the > claimed source. How is a client to know that civic data or geo data is not from a certain source? > o The mapping server SHOULD provide information to ensure that it is > authoritive for the provided information. Same as above. I don't understand how a machine, especially one that is trying to make a fast emergency call, will know that the server at IP address 10.0.0.1 is NOT authoritative for mapping 123 Main St. to a URI. If the basis is not on the data but on accreditation, then this needs to be called out. And this brings into question which trust anchors the client will use. I think Section 5.5 is out of scope for ECRIT. From Section 5.6 > When the query is issued on behalf of the mapping client then > the > mapping server must take necessary steps to determine > conclusively > that the data came from a genuine mapping server or an > authoritative mapping server (remote). > > If the query procedure is done by the client then the client > must > authenticate both the home mapping server and remote mapping > servers before accepting the response information. So the client has to contact two mapping servers? And both have to have the same information? From Section 5.7 > However, even if the AIP or ISP provides a signed location, it is > difficult to ensure that such a signed location object is only used > for calls from that location, as it will have to be copied from a > location delivery protocol to the call signaling protocol. For > example, a third party could obtain such a signed location > object and > use it elsewhere. Naturally, timestamps will restrict such > useage to > the order of minutes or hours, depending on how often location > information is updated. Wouldn't including the IP address in the signed data stop the location object from having validity outside the AIP/ISP network? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 26 17:11:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUsYI-0004BL-6l; Wed, 26 Oct 2005 17:11:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUsYG-0004AI-DB for ecrit@megatron.ietf.org; Wed, 26 Oct 2005 17:11:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25581 for ; Wed, 26 Oct 2005 17:11:00 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUslT-0004v4-T1 for ecrit@ietf.org; Wed, 26 Oct 2005 17:24:57 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j9QLBAWk004210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 Oct 2005 17:11:10 -0400 (EDT) Message-ID: <435FF0AA.5040808@cs.columbia.edu> Date: Wed, 26 Oct 2005 17:10:02 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Tschofenig, Hannes" Subject: Re: AW: [ECRIT]: Caller Identity requirements: replacementtext foremptysection in ECRIT req doc. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FRAUD_419_REFNUM 0, __FRAUD_419_TINHORN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by opus.cs.columbia.edu id j9QLBAWk004210 X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org One of the problems could be that we have different pictures in mind=20 when the word "architecture" is mentioned, e.g., whether this is for the=20 whole emergency call lifecycle or just the lookup part. At one level, I hope it's pretty simple: (0) The end system learns local emergency numbers [not currently=20 discussed, but there are proposals that trivially extend the existing=20 lookup/mapping work] and learns its own location [geopriv work, plus=20 others such as LLDP or GPS] (1) User on end system places emergency call; UA recognizes digits based=20 on step (0) and emergency call is identified by something [in scope, in=20 progress, with drafts] (2) Either the end system or some signaling proxy asks for a translation=20 of location to a PSAP URL. This request may have happened earlier for=20 non-mobile systems. The same system does validation in some way. [core=20 part of ECRIT; 3 proposals] (3) The call is routed to the URL returned, with the location=20 information attached in PIDF-LO [geopriv profile work]. The request=20 contains callback information (Contact/From), an identifier labeling=20 this as an emergency call [as in (1)]. If necessary, repeat (2) if the=20 original destination was some intermediary, such as a state-wide PSAP=20 routing box. [standard SIP routing; nothing special and no need for=20 additional work] (4) The end system may implement some special handling for services,=20 such as BYE or REFER [sipdev-req?]. Is there anything missing? Would it help to have a two-page version of=20 this written up? Henning Tschofenig, Hannes wrote: > hi all,=20 >=20 > a complete solution providing emergency service requires a number of th= ings to be in place and some of them are even outside the ietf.=20 >=20 > we develop important parts of the entire solution space. > i think that there is no problem with this.=20 >=20 > ciao > hannes >=20 >=20 >>-----Urspr=FCngliche Nachricht----- >>Von: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >>Im Auftrag von Andrew Newton >>Gesendet: Mittwoch, 26. Oktober 2005 18:57 >>An: Tom-PT Taylor >>Cc: ecrit@ietf.org >>Betreff: Re: [ECRIT]: Caller Identity requirements:=20 >>replacementtext foremptysection in ECRIT req doc. >> >> >>Given this message: http://www1.ietf.org/mail-archive/web/ecrit/=20 >>current/msg01077.html >>Perhaps the scope of ECRIT is even more restrictive in that we are =20 >>not even suppose to contemplate the other pieces that make the total =20 >>solution. >> >>I understand the IESG's reluctance to grant working group charters =20 >>for work that seems open ended, prone to rat holes, and quite=20 >>easy to =20 >>drive into the weeds. But I also think it equally unwise to be so =20 >>restrictive as to generate incomplete and/or unworkable solutions. >> >>-andy >> >>On Oct 24, 2005, at 4:36 PM, Tom-PT Taylor wrote: >> >> >>>I think you're under the mistaken impression that ECRIT is =20 >>>producing a complete solution to emergency service calling. That =20 >>>simply isn't so. The complete solution has to be worked in bodies =20 >>>that create architectures and not just protocols. >>> >>>Tim DUNN wrote: >>> >>> >>>>The PSAP needs is a location and a call back. Not providing both =20 >>>>is a reduction in existing capabilities in place for circuit =20 >>>>switched and mobile 911 calls. Both need to be accounted for =20 >>>>somewhere in this overall set of requirements/architecture. >>>> >>> >>> >>>_______________________________________________ >>>Ecrit mailing list >>>Ecrit@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ecrit >>> >> >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit >> >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 27 01:15:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV075-0008Ed-9h; Thu, 27 Oct 2005 01:15:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV06z-00085w-DF for ecrit@megatron.ietf.org; Thu, 27 Oct 2005 01:15:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24262 for ; Thu, 27 Oct 2005 01:15:20 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EV0KH-0008Ms-JA for ecrit@ietf.org; Thu, 27 Oct 2005 01:29:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [ECRIT]: Caller Identityrequirements: replacementtext foremptysection in ECRIT req doc. Date: Thu, 27 Oct 2005 07:19:04 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4636@oefeg-s04.oefeg.loc> Thread-Topic: [ECRIT]: Caller Identityrequirements: replacementtext foremptysection in ECRIT req doc. Thread-Index: AcXacqpgKcPPrNsBQHeJwWmQvSSl2wAQnKnh From: "Stastny Richard" To: "Henning Schulzrinne" , "Tschofenig, Hannes" X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org What I am missing is that the endsystem at any time before placing the emergency call may check if a PSAP may be reched with the given location: 1. checking that the current location resolves to a valid PSAP URI 2. checking that the PSAP given in this URI can be contacted, (without placing a real emergency call) 3. indicating the result to the end-user =20 I do not believe that additional protocol requirements result from this it should IMHO just mentioned =20 Richard ________________________________ Von: ecrit-bounces@ietf.org im Auftrag von Henning Schulzrinne Gesendet: Mi 26.10.2005 23:10 An: Tschofenig, Hannes Cc: ecrit@ietf.org Betreff: Re: AW: [ECRIT]: Caller Identityrequirements: replacementtext = foremptysection in ECRIT req doc. One of the problems could be that we have different pictures in mind when the word "architecture" is mentioned, e.g., whether this is for the whole emergency call lifecycle or just the lookup part. At one level, I hope it's pretty simple: (0) The end system learns local emergency numbers [not currently discussed, but there are proposals that trivially extend the existing lookup/mapping work] and learns its own location [geopriv work, plus others such as LLDP or GPS] (1) User on end system places emergency call; UA recognizes digits based on step (0) and emergency call is identified by something [in scope, in progress, with drafts] (2) Either the end system or some signaling proxy asks for a translation of location to a PSAP URL. This request may have happened earlier for non-mobile systems. The same system does validation in some way. [core part of ECRIT; 3 proposals] (3) The call is routed to the URL returned, with the location information attached in PIDF-LO [geopriv profile work]. The request contains callback information (Contact/From), an identifier labeling this as an emergency call [as in (1)]. If necessary, repeat (2) if the original destination was some intermediary, such as a state-wide PSAP routing box. [standard SIP routing; nothing special and no need for additional work] (4) The end system may implement some special handling for services, such as BYE or REFER [sipdev-req?]. Is there anything missing? Would it help to have a two-page version of this written up? Henning Tschofenig, Hannes wrote: > hi all, > > a complete solution providing emergency service requires a number of = things to be in place and some of them are even outside the ietf. > > we develop important parts of the entire solution space. > i think that there is no problem with this. > > ciao > hannes > > >>-----Urspr=FCngliche Nachricht----- >>Von: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>Im Auftrag von Andrew Newton >>Gesendet: Mittwoch, 26. Oktober 2005 18:57 >>An: Tom-PT Taylor >>Cc: ecrit@ietf.org >>Betreff: Re: [ECRIT]: Caller Identity requirements: >>replacementtext foremptysection in ECRIT req doc. >> >> >>Given this message: http://www1.ietf.org/mail-archive/web/ecrit/ >>current/msg01077.html >>Perhaps the scope of ECRIT is even more restrictive in that we are=20 >>not even suppose to contemplate the other pieces that make the total=20 >>solution. >> >>I understand the IESG's reluctance to grant working group charters=20 >>for work that seems open ended, prone to rat holes, and quite >>easy to=20 >>drive into the weeds. But I also think it equally unwise to be so=20 >>restrictive as to generate incomplete and/or unworkable solutions. >> >>-andy >> >>On Oct 24, 2005, at 4:36 PM, Tom-PT Taylor wrote: >> >> >>>I think you're under the mistaken impression that ECRIT is=20 >>>producing a complete solution to emergency service calling. That=20 >>>simply isn't so. The complete solution has to be worked in bodies=20 >>>that create architectures and not just protocols. >>> >>>Tim DUNN wrote: >>> >>> >>>>The PSAP needs is a location and a call back. Not providing both=20 >>>>is a reduction in existing capabilities in place for circuit=20 >>>>switched and mobile 911 calls. Both need to be accounted for=20 >>>>somewhere in this overall set of requirements/architecture. >>>> >>> >>> >>>_______________________________________________ >>>Ecrit mailing list >>>Ecrit@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ecrit >>> >> >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit >> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 27 04:46:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV3Ob-0000jr-T5; Thu, 27 Oct 2005 04: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 1EV3OW-0000hC-2T for ecrit@megatron.ietf.org; Thu, 27 Oct 2005 04:45:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16218 for ; Thu, 27 Oct 2005 04:45:40 -0400 (EDT) From: hannes.tschofenig@gmx.net Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EV3bq-00038z-7C for ecrit@ietf.org; Thu, 27 Oct 2005 04:59:42 -0400 Received: (qmail invoked by alias); 27 Oct 2005 08:45:40 -0000 Received: from ip-80-226-242-8.vodafone-net.de (EHLO [10.227.211.36]) [80.226.242.8] by mail.gmx.net (mp025) with SMTP; 27 Oct 2005 10:45:40 +0200 X-Authenticated: #29516787 To: "Stastny Richard" Subject: AW: Re: [ECRIT]: CallerIdentityrequirements: replacementtext forem ptysection in ECRITreq doc. Date: Thu, 27 Oct 2005 10:44:35 +0100 Message-ID: X-Mailer: EPOC Email Version 2.10 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Y-GMX-Trusted: 0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hannes.tschofenig@gmx.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi roger,=20 please find my comments inline. -- Urspr=C3=BCngl. Mitteil. -- Betreff: Re: [ECRIT]: CallerIdentityrequirements: replacementtext = foremptysection in ECRITreq doc. Von: "Stastny Richard" Datum: 27.10.2005 06:19 What I am missing is that the endsystem at any time before placing the emergency call may check if a PSAP may be reched with the given location: 1. checking that the current location resolves to a valid PSAP URI # this requirement is currently in the req. doc. 2. checking that the PSAP given in this URI can be contacted, (without placing a real emergency call) # in one of the old requirements drafts we had such a requirement in there. = 3. indicating the result to the end-user # what result to you accept? something that goes beyond what sip already = provides? =20 I do not believe that additional protocol requirements result from = this it should IMHO just mentioned =20 Richard # ciao=20 hannes ________________________________ Von: ecrit-bounces@ietf.org im Auftrag von Henning Schulzrinne Gesendet: Mi 26.10.2005 23:10 An: Tschofenig, Hannes Cc: ecrit@ietf.org Betreff: Re: AW: [ECRIT]: Caller Identityrequirements: replacementtext = foremptysection in ECRIT req doc. One of the problems could be that we have different pictures in mind when the word "architecture" is mentioned, e.g., whether this is for = the whole emergency call lifecycle or just the lookup part. At one level, I hope it's pretty simple: (0) The end system learns local emergency numbers [not currently discussed, but there are proposals that trivially extend the existing lookup/mapping work] and learns its own location [geopriv work, plus others such as LLDP or GPS] (1) User on end system places emergency call; UA recognizes digits = based on step (0) and emergency call is identified by something [in scope, = in progress, with drafts] (2) Either the end system or some signaling proxy asks for a = translation of location to a PSAP URL. This request may have happened earlier for non-mobile systems. The same system does validation in some way. = [core part of ECRIT; 3 proposals] (3) The call is routed to the URL returned, with the location information attached in PIDF-LO [geopriv profile work]. The request contains callback information (Contact/From), an identifier labeling this as an emergency call [as in (1)]. If necessary, repeat (2) if = the original destination was some intermediary, such as a state-wide PSAP routing box. [standard SIP routing; nothing special and no need for additional work] (4) The end system may implement some special handling for services, such as BYE or REFER [sipdev-req?]. Is there anything missing? Would it help to have a two-page version = of this written up? Henning Tschofenig, Hannes wrote: > hi all, > > a complete solution providing emergency service requires a number of = things to be in place and some of them are even outside the ietf. > > we develop important parts of the entire solution space. > i think that there is no problem with this. > > ciao > hannes > > >>-----Urspr=C3=BCngliche Nachricht----- >>Von: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>Im Auftrag von Andrew Newton >>Gesendet: Mittwoch, 26. Oktober 2005 18:57 >>An: Tom-PT Taylor >>Cc: ecrit@ietf.org >>Betreff: Re: [ECRIT]: Caller Identity requirements: >>replacementtext foremptysection in ECRIT req doc. >> >> >>Given this message: http://www1.ietf.org/mail-archive/web/ecrit/ >>current/msg01077.html >>Perhaps the scope of ECRIT is even more restrictive in that we are = >>not even suppose to contemplate the other pieces that make the total = >>solution. >> >>I understand the IESG's reluctance to grant working group charters = >>for work that seems open ended, prone to rat holes, and quite >>easy to=20 >>drive into the weeds. But I also think it equally unwise to be so = >>restrictive as to generate incomplete and/or unworkable solutions. >> >>-andy >> >>On Oct 24, 2005, at 4:36 PM, Tom-PT Taylor wrote: >> >> >>>I think you're under the mistaken impression that ECRIT is=20 >>>producing a complete solution to emergency service calling. That = >>>simply isn't so. The complete solution has to be worked in bodies = >>>that create architectures and not just protocols. >>> >>>Tim DUNN wrote: >>> >>> >>>>The PSAP needs is a location and a call back. Not providing both = >>>>is a reduction in existing capabilities in place for circuit=20 >>>>switched and mobile 911 calls. Both need to be accounted for=20 >>>>somewhere in this overall set of requirements/architecture. >>>> >>> >>> >>>_______________________________________________ >>>Ecrit mailing list >>>Ecrit@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ecrit >>> >> >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit >> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 27 05:20:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV3vX-0005L4-8A; Thu, 27 Oct 2005 05:20:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV3vV-0005Kg-0s for ecrit@megatron.ietf.org; Thu, 27 Oct 2005 05:20:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17450 for ; Thu, 27 Oct 2005 05:19:44 -0400 (EDT) From: hannes.tschofenig@gmx.net Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EV48p-0003w2-57 for ecrit@ietf.org; Thu, 27 Oct 2005 05:33:47 -0400 Received: (qmail invoked by alias); 27 Oct 2005 09:19:43 -0000 Received: from ip-80-226-246-169.vodafone-net.de (EHLO [10.226.210.204]) [80.226.246.169] by mail.gmx.net (mp025) with SMTP; 27 Oct 2005 11:19:43 +0200 X-Authenticated: #29516787 To: Henning Schulzrinne Subject: AW: Re: AW: [ECRIT]: Caller Identityrequirements: replacementtext foremptysection in ECRIT req doc. Date: Thu, 27 Oct 2005 11:18:35 +0100 Message-ID: X-Mailer: EPOC Email Version 2.10 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Y-GMX-Trusted: 0 X-Spam-Score: 1.3 (+) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hannes.tschofenig@gmx.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi henning,=20 thanks for the summary. i think your list shows quite well that we are = covering most aspects since we can benefit from work in other ietf working = groups (e.g., geopriv).=20 regarding the architectural issues. sure, it is true that it is difficult = to agree on architectures. however, i think that we do not need to agree on = an architecture but we need to understand what implications the different = architectures have for our work. even if you favor a different architecture = then you still might want to use certain building blocks that are currently = being developed. =20 regarding issue (0) it is true that we still have some open issues. = ciao hannes -- Urspr=C3=BCngl. Mitteil. -- Betreff: Re: AW: [ECRIT]: Caller Identityrequirements: replacementtext = foremptysection in ECRIT req doc. Von: Henning Schulzrinne Datum: 26.10.2005 22:10 One of the problems could be that we have different pictures in mind = when the word "architecture" is mentioned, e.g., whether this is for the = whole emergency call lifecycle or just the lookup part. At one level, I hope it's pretty simple: (0) The end system learns local emergency numbers [not currently=20 discussed, but there are proposals that trivially extend the existing = lookup/mapping work] and learns its own location [geopriv work, plus = others such as LLDP or GPS] (1) User on end system places emergency call; UA recognizes digits based = on step (0) and emergency call is identified by something [in scope, in = progress, with drafts] (2) Either the end system or some signaling proxy asks for a translation = of location to a PSAP URL. This request may have happened earlier for = non-mobile systems. The same system does validation in some way. [core = part of ECRIT; 3 proposals] (3) The call is routed to the URL returned, with the location=20 information attached in PIDF-LO [geopriv profile work]. The request = contains callback information (Contact/From), an identifier labeling = this as an emergency call [as in (1)]. If necessary, repeat (2) if the = original destination was some intermediary, such as a state-wide PSAP = routing box. [standard SIP routing; nothing special and no need for = additional work] (4) The end system may implement some special handling for services, = such as BYE or REFER [sipdev-req?]. Is there anything missing? Would it help to have a two-page version of = this written up? Henning Tschofenig, Hannes wrote: > hi all,=20 >=20 > a complete solution providing emergency service requires a number of = things to be in place and some of them are even outside the ietf.=20 >=20 > we develop important parts of the entire solution space. > i think that there is no problem with this.=20 >=20 > ciao > hannes >=20 >=20 >>-----Urspr=C3=BCngliche Nachricht----- >>Von: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >>Im Auftrag von Andrew Newton >>Gesendet: Mittwoch, 26. Oktober 2005 18:57 >>An: Tom-PT Taylor >>Cc: ecrit@ietf.org >>Betreff: Re: [ECRIT]: Caller Identity requirements:=20 >>replacementtext foremptysection in ECRIT req doc. >> >> >>Given this message: http://www1.ietf.org/mail-archive/web/ecrit/=20 >>current/msg01077.html >>Perhaps the scope of ECRIT is even more restrictive in that we are = >>not even suppose to contemplate the other pieces that make the total = >>solution. >> >>I understand the IESG's reluctance to grant working group charters = >>for work that seems open ended, prone to rat holes, and quite=20 >>easy to =20 >>drive into the weeds. But I also think it equally unwise to be so = >>restrictive as to generate incomplete and/or unworkable solutions. >> >>-andy >> >>On Oct 24, 2005, at 4:36 PM, Tom-PT Taylor wrote: >> >> >>>I think you're under the mistaken impression that ECRIT is =20 >>>producing a complete solution to emergency service calling. That = >>>simply isn't so. The complete solution has to be worked in bodies = >>>that create architectures and not just protocols. >>> >>>Tim DUNN wrote: >>> >>> >>>>The PSAP needs is a location and a call back. Not providing both = >>>>is a reduction in existing capabilities in place for circuit =20 >>>>switched and mobile 911 calls. Both need to be accounted for =20 >>>>somewhere in this overall set of requirements/architecture. >>>> >>> >>> >>>_______________________________________________ >>>Ecrit mailing list >>>Ecrit@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ecrit >>> >> >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit >> >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 27 05:33:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV48i-0006Hs-Ut; Thu, 27 Oct 2005 05:33:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV48h-0006GY-Pb for ecrit@megatron.ietf.org; Thu, 27 Oct 2005 05:33:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18057 for ; Thu, 27 Oct 2005 05:33:23 -0400 (EDT) From: hannes.tschofenig@gmx.net Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EV4M1-0004Gl-0n for ecrit@ietf.org; Thu, 27 Oct 2005 05:47:26 -0400 Received: (qmail invoked by alias); 27 Oct 2005 09:33:24 -0000 Received: from ip-80-226-235-201.vodafone-net.de (EHLO [10.226.214.140]) [80.226.235.201] by mail.gmx.net (mp003) with SMTP; 27 Oct 2005 11:33:24 +0200 X-Authenticated: #29516787 To: Andrew Newton Subject: AW: Re: [ECRIT]: Caller Identity requirements:replacementtext fore mptysection in ECRIT req doc. Date: Thu, 27 Oct 2005 11:32:20 +0100 Message-ID: X-Mailer: EPOC Email Version 2.10 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Y-GMX-Trusted: 0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hannes.tschofenig@gmx.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi andy, i would like to address the question whether we need to understand the = architecture before we make progress on the requirements: it is always good = to understand everything in great detail before you progress the work. = unfortunately, this does not seem to possible in all cases and it might not = be possible to produce timely results.=20 i think that there are some core parts in our charter that will most likely = be needed in every architecture supporting emergency services. if we = recognize that some additional parts are needed then we can think about = adding them to the charter.=20 ciao hannes -- Urspr=C3=BCngl. Mitteil. -- Betreff: Re: [ECRIT]: Caller Identity requirements:replacementtext = foremptysection in ECRIT req doc. Von: Andrew Newton Datum: 26.10.2005 19:30 On Oct 26, 2005, at 1:58 PM, Marc Linsner wrote: > Emergency Context Routing - I think the operative word is = 'routing'. In the title of this working group, the operative word is =20 "resolution". :) > Alternatively, I also believe that ECRIT would be moving faster if = > there was > common understanding to an overall architecture, which is why =20 > Hannes and I > don't want to deter such contributions along this topic, yet we =20 > must keep > moving towards the chartered goals. I agree that we would be moving faster if there were a common =20 understanding for the architecture. But why produce a solution =20 before you understand the architecture? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 27 06:37:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV58m-0008L4-JW; Thu, 27 Oct 2005 06:37:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV58k-0008Ik-0s for ecrit@megatron.ietf.org; Thu, 27 Oct 2005 06:37:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20734 for ; Thu, 27 Oct 2005 06:37:29 -0400 (EDT) From: hannes.tschofenig@gmx.net Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EV5M5-0005qn-2d for ecrit@ietf.org; Thu, 27 Oct 2005 06:51:33 -0400 Received: (qmail invoked by alias); 27 Oct 2005 10:37:29 -0000 Received: from ip-80-226-243-179.vodafone-net.de (EHLO [10.226.200.138]) [80.226.243.179] by mail.gmx.net (mp006) with SMTP; 27 Oct 2005 12:37:29 +0200 X-Authenticated: #29516787 To: Andrew Newton Subject: AW: [Ecrit] thoughts on draft-taylor-ecrit-security-threats-00 Date: Thu, 27 Oct 2005 12:36:25 +0100 Message-ID: X-Mailer: EPOC Email Version 2.10 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Y-GMX-Trusted: 0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Content-Transfer-Encoding: quoted-printable Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hannes.tschofenig@gmx.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi andy, thanks for the draft review. please find some comments inline: -- Urspr=C3=BCngl. Mitteil. -- Betreff: [Ecrit] thoughts on draft-taylor-ecrit-security-threats-00 Von: Andrew Newton Datum: 26.10.2005 21:15 Here are my comments on the security threats and requirements = document. Overall, I like the format and structure of the document. The =20 authors have done a good job. However, I am concerned about the security requirements from two main = perspectives: a) First, I question whether or not they are overly burdensome with = regard to performance. Invoking channel security is more than just a = few roundtrips and is CPU intensive.=20 # that's true. the most difficult part is related to the key management. do = we demand authentication of the mapping server to the mapping client? = Additionally, the requirement =20 for object signing may be even more burdensome, as it requires the = triple of location info, URI, and timestamp (that's a lot of data to = sign -- especially in the geo x,y,z case, and just how often does it = need resigning). And I certainly don't think both of these measures = are required. the aspect of object signing is certainly difficult and we haven't reached = conclusion with regard this issue. in past discussions we said that the = mapping client will not verify the source of the provided mapping = information as part of the digital signature. sometimes we argued that the = psap might be interested in this information to determine the authenticity = of the provided information. b) There is no discussion regarding what a user would do if =20 authentication fails. What does it mean? Do they just put down the = phone and let their house burn down? Or do they continue on with the = call in hopes that the authentication failure is false indicator? # would this info need to go into a threats / requirements document?we can = certainly discuss it but i guess the main answer is: "if you fail to = perform the security checks, for example because a certificate status check = fails" you still continue." i will respond to your other comments later.=20 ciao hannes Anyway, here are my comments: From Section 1: > As a corollary, the present document > does not distinguish between the case where location is provided by > reference and the case where it is provided by value within session > signalling. If both location by reference and location by value are to be part of = the solution, then I think the security differences between the two = should be enumerated. Is this planned for a future rev, or is this = analysis pending a decision on the use of location by reference? From Section 4.3.1.1 > To avoid > launching DoS, the mapping server should be capable of limiting the > queries from a single IP, especially when an anonymous mapping is > requested, at a particular time. I keyed in on the word "anonymous". Perhaps this is one of those =20 cases where there is no agreement on the requirement, but I thought = ALL mapping requests would be anonymous. As in, no user information = is sent to the mapping server. From Section 4.3.2 > An adversary might run a faked mapping server aiming to pretend = that > it is a legitimate server. This would lead an emergency caller to > get bogus URI(s) that hinder a caller not to avail the emergency > service. It is necessary for the client to authenticate and = possibly > to authorize the mapping server as part of the emergency call > procedure. Taking the last part first, I'm not sure how a client is to authorize = the use of a mapping server. This needs to be explained. With regard to authentication of the mapping server, I do not agree = that this is necessary for three reasons: a) With authentication of the mapping server, I'm assume that this = refers to some sort of crypto, most likely TLS. There are two =20 implications here: there is a performance penalty for every mapping = request and there is the overhead of getting client vendors and =20 server operators to agree upon trust anchors. b) What does the usage scenario say about an improper =20 authentication? If the mapping server does not authenticate, is the = call dropped? c) There is another alternative, which is to sign the data the server = gives back. From Section 4.3.2.1 > Channel Security: It is possible to establish a secure channel = e.g., > TLS to ensure the authenticity of the given mapped information. > Additionally, there are several advantages in establishing a > secure channel such as confidentiality protection, replay > protection and in case if the mapping server realizes that it is > under flooding attack (query) it might also request the > certificate, if available, to verify the identity of the > requesting client. Consequently, this step might decrease the > performance of the mapping service since the certificate > processing and key exchange mechanism pose serious performance > degradation for the mapping server. I think authentication of the client with user-based certs (assigned = to individuals) is unlikely to see deployment in our life times. =20 Using vender assigned certs is a much more reasonable idea, but it = suffers from the flea market problem. > Object Security: It is possible to use object security e.g., S/MIME > to sign the individual information in the query/response message > of the mapping service. This mechanism with various settings = also > provides authentication, a degree of confidentiality protection = of > the sender and prevents from the replay attacks. Things like S/MIME are vulnerable to replay, and therefore object =20 security is of little benefit. Perhaps the proper term needed is =20 transaction signing. A request is made, and the response contains a = signed answer plus transaction ID (something from the request). From Section 5.4 > o The maping client MUST be able to authenticate the mapping = server. Covered above. > o The mapping server MUST be provide data origin authentication > thereby ensuring that the provided data items are indeed from = the > claimed source. How is a client to know that civic data or geo data is not from a =20 certain source? > o The mapping server SHOULD provide information to ensure that it = is > authoritive for the provided information. Same as above. I don't understand how a machine, especially one that = is trying to make a fast emergency call, will know that the server at = IP address 10.0.0.1 is NOT authoritative for mapping 123 Main St. to = a URI. If the basis is not on the data but on accreditation, then this needs = to be called out. And this brings into question which trust anchors = the client will use. I think Section 5.5 is out of scope for ECRIT. From Section 5.6 > When the query is issued on behalf of the mapping client then = > the > mapping server must take necessary steps to determine =20 > conclusively > that the data came from a genuine mapping server or an > authoritative mapping server (remote). > > If the query procedure is done by the client then the client = > must > authenticate both the home mapping server and remote mapping > servers before accepting the response information. So the client has to contact two mapping servers? And both have to = have the same information? From Section 5.7 > However, even if the AIP or ISP provides a signed location, it = is > difficult to ensure that such a signed location object is only = used > for calls from that location, as it will have to be copied from = a > location delivery protocol to the call signaling protocol. For > example, a third party could obtain such a signed location =20 > object and > use it elsewhere. Naturally, timestamps will restrict such =20 > useage to > the order of minutes or hours, depending on how often location > information is updated. Wouldn't including the IP address in the signed data stop the =20 location object from having validity outside the AIP/ISP network? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 27 09:11:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV7XJ-0002gW-Se; Thu, 27 Oct 2005 09:11:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV7XG-0002aa-2f for ecrit@megatron.ietf.org; Thu, 27 Oct 2005 09:11:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27869 for ; Thu, 27 Oct 2005 09:10:58 -0400 (EDT) Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EV7kc-0001PC-TT for ecrit@ietf.org; Thu, 27 Oct 2005 09:25:03 -0400 Received: (qmail invoked by alias); 27 Oct 2005 13:10:52 -0000 Received: from ip-80-226-240-73.vodafone-net.de (EHLO [10.227.214.32]) [80.226.240.73] by mail.gmx.net (mp005) with SMTP; 27 Oct 2005 15:10:52 +0200 X-Authenticated: #29516787 Message-ID: <4360D1D3.1060409@gmx.net> Date: Thu, 27 Oct 2005 15:10:43 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Haluska, John J" Subject: Re: [Ecrit] Comment on Security Threats Draft: Single IP source as potential DoS indication References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi john, thanks for your feedback. please find a response below: Haluska, John J wrote: > > > There are several places (4.2.1.1 and 4.3.1.1) in > draft-taylor-ecrit-security-threats-00.txt where the origination of a > large number of emergency calls or mapping queries from a single IP > address is equated with a potential DoS attack. I would suggest that > there should be a caveat here that _/sometimes/_ this is perfectly > legitimate. i hope we did not give the impression that a large number of emergency calls from the same ip address might be an indication of a dos attack. i agree that the term 'ip address checking' in section 4.2.1.1 is proably not well chosen. the text in this paragraph should also be rephrased. this particularly relates to the following paragraph: " IP address checking: Some types of attacks can be limited to a single instance per attacker by tracing the signaling request of the caller. This may well be effective in preventing some kinds of DDOS attacks as well as the attempt of a single attacker to place multiple emergency calls in succession. This remedy may be limited if the attacker is able to "launder" signaling or media packets through a variety of intermediaries. IP address tracing may also be helpful in apprehending a malcreant later. Thus, signaling protocols should try to capture as much of the request history, including the source of the mapping request, as possible. " i think that the text should be phrased in a way that it stresses the ability to use ip trackback mechanisms to learn more information. the same applies to the following section: " 4.3.1.1. Countermeasures Generic DoS attacks, such as SYN flooding, can be handled by using best current practices and hence it is not discussed here. To avoid launching DoS, the mapping server should be capable of limiting the queries from a single IP, especially when an anonymous mapping is requested, at a particular time. This limit should consider the proxy case. It may also log the relevant information like IP address, query information from the requests in order to indicate the query flooding. Dealing with all sorts of denial of service attacks against the emergency infrastructure and at directory servers is difficult. Protection needs to be provided at different protocol layers and also at different locations in the network. Additionally, it is essential to ensure that directory queries submitted by adversary towards the directory server do not cause a major performance impact for the server with the consequence that potentially genuine requests may need to be rejected due to overload and a timely response is not possible. " i am also not convinced that mechanisms enforced at the psap or the mapping server should be based on IP addresses. i think that it would even be harmful to block requests from certain IP addresses. > > > > For example, an emergency could occur in an office building where a > single large device handles many lines, then all the signaling and media > could come from the same IP address for all the calls. Or a Call Agent > (e.g. PacketCable CMS in a cable MSO) handling many subscriber lines > might utilize an all-IP emergency service, then all mapping queries and > signaling might come from the same address, and some large media gateway > or session border controller might generate lots of media streams with > the same source IP address. > i fully agree with you. the same would happen if you have a large network behind a nat. for the entity outside this network, such as a psap or a mapping server, all requests might have the same address (depending on the type of nat). my conclusion: the text needs to be fixed. thanks for pointing to this issue. ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 27 09:25:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV7lT-0002Dt-8l; Thu, 27 Oct 2005 09:25:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV7lR-0002Da-Sl for ecrit@megatron.ietf.org; Thu, 27 Oct 2005 09:25:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28672 for ; Thu, 27 Oct 2005 09:25:38 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV7yn-0001pK-3e for ecrit@ietf.org; Thu, 27 Oct 2005 09:39:43 -0400 Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net [141.153.174.94]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j9RDPi4l029789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 27 Oct 2005 09:25:45 -0400 (EDT) Message-ID: <4360D563.5030700@cs.columbia.edu> Date: Thu, 27 Oct 2005 09:25:55 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard Subject: Re: [ECRIT]: Caller Identityrequirements: replacementtext foremptysection in ECRIT req doc. References: <32755D354E6B65498C3BD9FD496C7D462C4636@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4636@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.2 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Stastny Richard wrote: > What I am missing is that the endsystem at any time before placing > the emergency call may check if a PSAP may be reched with the > given location: > 1. checking that the current location resolves to a valid PSAP URI Mentioned in a previous discussion; uses the same resolution protocol, but means that it is necessary that said resolution protocol is accessible to end systems. > 2. checking that the PSAP given in this URI can be contacted, > (without placing a real emergency call) This is probably something to be discussed in conjunction with the call identification problem. There are two basic solutions: - create a new 'test' emergency service, but that doesn't allow testing separate services - add a "this is a test" flag to the identification so that the PSAP operator/call handling logic can recognize this as a test and (e.g.,) send the call to an auto-answer robot ("Hi, you have reached..."). My inclination is to do the latter. If that's done, the end system wanting to do a test just goes through the regular procedure, except for setting the "this is a test" flag. That way, all aspects of the system are tested under near-real conditions. > 3. indicating the result to the end-user > > I do not believe that additional protocol requirements result from this > it should IMHO just mentioned I agree with the basic requirements, but I was trying to avoid writing a two-page draft in an email... Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 27 10:24:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV8gR-00009Z-7K; Thu, 27 Oct 2005 10:24:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV8gP-000091-Oa for ecrit@megatron.ietf.org; Thu, 27 Oct 2005 10:24:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02800 for ; Thu, 27 Oct 2005 10:24:29 -0400 (EDT) Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EV8tm-0003qR-5O for ecrit@ietf.org; Thu, 27 Oct 2005 10:38:34 -0400 Received: (qmail invoked by alias); 27 Oct 2005 14:24:29 -0000 Received: from ip-80-226-237-181.vodafone-net.de (EHLO [10.226.199.80]) [80.226.237.181] by mail.gmx.net (mp031) with SMTP; 27 Oct 2005 16:24:29 +0200 X-Authenticated: #29516787 Message-ID: <4360E30D.6090801@gmx.net> Date: Thu, 27 Oct 2005 16:24:13 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] thoughts on draft-taylor-ecrit-security-threats-00 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.2 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi andy, here is the second part of my response: ~snip~ > Anyway, here are my comments: > > From Section 1: > >> As a corollary, the present document >> does not distinguish between the case where location is provided by >> reference and the case where it is provided by value within session >> signalling. > > > If both location by reference and location by value are to be part of > the solution, then I think the security differences between the two > should be enumerated. Is this planned for a future rev, or is this > analysis pending a decision on the use of location by reference? it is currently not clear whether we will both approaches. the use of reference is not uncontroversal. in any case, we should reflect this. as such, i think that a future version of the document could talk a bit more about this subject, if it turns out to be relevant for us. > > From Section 4.3.1.1 > >> To avoid >> launching DoS, the mapping server should be capable of limiting the >> queries from a single IP, especially when an anonymous mapping is >> requested, at a particular time. > > > I keyed in on the word "anonymous". Perhaps this is one of those cases > where there is no agreement on the requirement, but I thought ALL > mapping requests would be anonymous. As in, no user information is > sent to the mapping server. if the end host queries the mapping server then i fully agree with you. it might, however, be the case that a proxy server that invokes a query to the mapping server. it might, however, be good to phrase this in a different way. > > From Section 4.3.2 > >> An adversary might run a faked mapping server aiming to pretend that >> it is a legitimate server. This would lead an emergency caller to >> get bogus URI(s) that hinder a caller not to avail the emergency >> service. It is necessary for the client to authenticate and possibly >> to authorize the mapping server as part of the emergency call >> procedure. > > > Taking the last part first, I'm not sure how a client is to authorize > the use of a mapping server. This needs to be explained. the problem is the following: do we want to prevent the case where a client is provided false uri's? if yes, then we need to make sure that the emergency caller talks to an entity that is actually allowed to operate as a psap. how do you verify this? one way (and this is a solution specific discussion) is to place certain information into the certificate. authentication is clearly not sufficient. > > With regard to authentication of the mapping server, I do not agree > that this is necessary for three reasons: > > a) With authentication of the mapping server, I'm assume that this > refers to some sort of crypto, most likely TLS. There are two > implications here: there is a performance penalty for every mapping > request and there is the overhead of getting client vendors and server > operators to agree upon trust anchors. i am not sure about the performance impact of running tls. that does not seem to be the most difficult part, at least not for today's equipment. i agree with regard to the trust anchors. that's indeed a difficult part. > > b) What does the usage scenario say about an improper authentication? > If the mapping server does not authenticate, is the call dropped? correction: the mapping client authenticates the mapping server. if the mapping client cannot authenticate the server then it can decide what todo. at least it has the chance to verify something. > > c) There is another alternative, which is to sign the data the server > gives back. do you refer to the original source of the information or the mapping server that directly talks to the mapping client? if you talk about the former one then i need to remember you to appendix a of . an overall comment: do you think that there should not be any security between the mapping client and the mapping server. if you think so then we certainly have no way to prevent a number of attacks. this does not seem to be attractive either. providing at least the possibity to prevent these attacks is worth thinking about it. > > From Section 4.3.2.1 > >> Channel Security: It is possible to establish a secure channel e.g., >> TLS to ensure the authenticity of the given mapped information. >> Additionally, there are several advantages in establishing a >> secure channel such as confidentiality protection, replay >> protection and in case if the mapping server realizes that it is >> under flooding attack (query) it might also request the >> certificate, if available, to verify the identity of the >> requesting client. Consequently, this step might decrease the >> performance of the mapping service since the certificate >> processing and key exchange mechanism pose serious performance >> degradation for the mapping server. > > > I think authentication of the client with user-based certs (assigned to > individuals) is unlikely to see deployment in our life times. Using > vender assigned certs is a much more reasonable idea, but it suffers > from the flea market problem. this referred primarily to a non-end user that requests the mapping. furthermore, i would like to mention our discussion at the ietf#63 geopriv meeting when we spoke about the ability to prevent denial of service attack and the usage of end-to-end security using special client side certificates was seen as a potential way to address some of the problems (note that credentials that are different to the credentials used for service access or network access). > >> Object Security: It is possible to use object security e.g., S/MIME >> to sign the individual information in the query/response message >> of the mapping service. This mechanism with various settings also >> provides authentication, a degree of confidentiality protection of >> the sender and prevents from the replay attacks. > > > Things like S/MIME are vulnerable to replay, and therefore object > security is of little benefit. Perhaps the proper term needed is > transaction signing. A request is made, and the response contains a > signed answer plus transaction ID (something from the request). you are right. s/mime itself does not provide protection against replay attacks. the term "transaction security" seems to be appropriate. the aspect of object signaling needs to receive more attention particularly with regard to replay protection prevention. > > From Section 5.4 > >> o The maping client MUST be able to authenticate the mapping server. > > > Covered above. > >> o The mapping server MUST be provide data origin authentication >> thereby ensuring that the provided data items are indeed from the >> claimed source. > > > How is a client to know that civic data or geo data is not from a > certain source? this was intentionally phrased provocative. that's indeed difficult... good question. > >> o The mapping server SHOULD provide information to ensure that it is >> authoritive for the provided information. > > > Same as above. I don't understand how a machine, especially one that > is trying to make a fast emergency call, will know that the server at > IP address 10.0.0.1 is NOT authoritative for mapping 123 Main St. to a > URI. > > If the basis is not on the data but on accreditation, then this needs > to be called out. And this brings into question which trust anchors > the client will use. this is actually quite difficult. essentially, if you want to ensure that the information provided by a specific mapping server X is correct then the parent of this server needs to assertion that mapping server X is responsible for a certain geographical area. i don't know whether we want to have this feature or not? maybe this functionality is more important for the server-to-server communication part (that is currently outside the scope of our work). > > I think Section 5.5 is out of scope for ECRIT. > true. > From Section 5.6 > >> When the query is issued on behalf of the mapping client then the >> mapping server must take necessary steps to determine conclusively >> that the data came from a genuine mapping server or an >> authoritative mapping server (remote). >> >> If the query procedure is done by the client then the client must >> authenticate both the home mapping server and remote mapping >> servers before accepting the response information. > > > So the client has to contact two mapping servers? And both have to > have the same information? i think that this section is very misleading. i either suggest to delete it or to entirely rephrase it. > > From Section 5.7 > >> However, even if the AIP or ISP provides a signed location, it is >> difficult to ensure that such a signed location object is only used >> for calls from that location, as it will have to be copied from a >> location delivery protocol to the call signaling protocol. For >> example, a third party could obtain such a signed location object and >> use it elsewhere. Naturally, timestamps will restrict such useage to >> the order of minutes or hours, depending on how often location >> information is updated. > > > Wouldn't including the IP address in the signed data stop the location > object from having validity outside the AIP/ISP network? including the ip address in the signed information blob might work in some areas but it does not work if you are in a network that uses a private address space. thanks for the review. we certainly need to update the text. ciao hannes > > -andy > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 27 15:02:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVD1A-0007vH-0Y; Thu, 27 Oct 2005 15:02:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVD17-0007vB-O7 for ecrit@megatron.ietf.org; Thu, 27 Oct 2005 15:02:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22836 for ; Thu, 27 Oct 2005 15:02:08 -0400 (EDT) Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVDEX-0007cE-8g for ecrit@ietf.org; Thu, 27 Oct 2005 15:16:17 -0400 Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Thu, 27 Oct 2005 15:02:02 -0400 id 0158800A.4361242A.00007C18 In-Reply-To: <4360E30D.6090801@gmx.net> References: <4360E30D.6090801@gmx.net> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <125E799A-ADF5-4236-BFC0-930B6EBDAC4F@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] thoughts on draft-taylor-ecrit-security-threats-00 Date: Thu, 27 Oct 2005 15:02:15 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.2 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org It just occured to me that this document does not address two areas: security and threats in location delivery (dhcp, etc..) and security and threats of PSAP boundaries. These are things that need to be discussed. Anyway, my reply is in-line: On Oct 27, 2005, at 10:24 AM, Hannes Tschofenig wrote: >> From Section 4.3.1.1 >> >>> To avoid >>> launching DoS, the mapping server should be capable of limiting the >>> queries from a single IP, especially when an anonymous mapping is >>> requested, at a particular time. >>> >> I keyed in on the word "anonymous". Perhaps this is one of those >> cases where there is no agreement on the requirement, but I >> thought ALL mapping requests would be anonymous. As in, no user >> information is sent to the mapping server. >> > > if the end host queries the mapping server then i fully agree with > you. > it might, however, be the case that a proxy server that invokes a > query to the mapping server. I still do not understand. Why would user information be present if a proxy queries the LCMS? Again, I thought ALL mapping requests would be anonymous. >> From Section 4.3.2 >> >>> An adversary might run a faked mapping server aiming to pretend that >>> it is a legitimate server. This would lead an emergency caller to >>> get bogus URI(s) that hinder a caller not to avail the emergency >>> service. It is necessary for the client to authenticate and >>> possibly >>> to authorize the mapping server as part of the emergency call >>> procedure. >>> >> Taking the last part first, I'm not sure how a client is to >> authorize the use of a mapping server. This needs to be explained. >> > > the problem is the following: do we want to prevent the case where > a client is provided false uri's? if yes, then we need to make sure > that the emergency caller talks to an entity that is actually > allowed to operate as a psap. how do you verify this? one way (and > this is a solution specific discussion) is to place certain > information into the certificate. authentication is clearly not > sufficient. There is a difference between authentication and authorization. It seems that once a client has authenticated the identity of the server, full authorization is automatic. If, however, there is a different authorization step or perhaps the client authorizes the server for use in only geo mapping or whatever, I am at a loss to know what that is or how it would work. >> With regard to authentication of the mapping server, I do not >> agree that this is necessary for three reasons: >> a) With authentication of the mapping server, I'm assume that >> this refers to some sort of crypto, most likely TLS. There are >> two implications here: there is a performance penalty for every >> mapping request and there is the overhead of getting client >> vendors and server operators to agree upon trust anchors. >> > > i am not sure about the performance impact of running tls. that > does not seem to be the most difficult part, at least not for > today's equipment. First, I'd rather see the requirement specified in what function we want (i.e. we want integrity of the mapping answers) instead of a requirement specifying implementation (i.e. it must be channel security). There may be other ways to do this. I would also not take the implications of TLS so lightly. Not only does it mean crypto hardware, but it also means you have to get TCP load balancers. Also, estimates of load cannot be based on current 911 call load. It is likely to be much higher. If we are talking about end devices that make a query every time they connect to a network, that is a load that is orders of magnitude higher than current 911 call load. > i agree with regard to the trust anchors. that's indeed a difficult > part. Actually, after thinking about this, there is a simple answer: let the Internet Attachment Provider specify the trust anchor... after all, its specifying all sorts of other information that is essential for this to work. >> c) There is another alternative, which is to sign the data the >> server gives back. >> > > do you refer to the original source of the information or the > mapping server that directly talks to the mapping client? if you > talk about the former one then i need to remember you to appendix a > of . My point was that channel security is not the only option here. I'm still doubtful with the overall need. See below. > an overall comment: > do you think that there should not be any security between the > mapping client and the mapping server. if you think so then we > certainly have no way to prevent a number of attacks. this does not > seem to be attractive either. providing at least the possibity to > prevent these attacks is worth thinking about it. So which attacks does adding channel security or object/transaction signing prevent? It doesn't stop an attacker's ability to DoS the LCMS. In fact, it makes it easier. It doesn't stop an attacker from jamming the communication between a particular client and a server. What it does do is stop a spoofed answer. If everyday life were an episode of "24" and Jack Bauer needed to be sure he was not giving his position away to assassins, then this is a problem we need to worry about. Is such a thing really a high priority problem? >> From Section 4.3.2.1 >> >>> Channel Security: It is possible to establish a secure channel e.g., >>> TLS to ensure the authenticity of the given mapped information. >>> Additionally, there are several advantages in establishing a >>> secure channel such as confidentiality protection, replay >>> protection and in case if the mapping server realizes that it is >>> under flooding attack (query) it might also request the >>> certificate, if available, to verify the identity of the >>> requesting client. Consequently, this step might decrease the >>> performance of the mapping service since the certificate >>> processing and key exchange mechanism pose serious performance >>> degradation for the mapping server. >>> >> I think authentication of the client with user-based certs >> (assigned to individuals) is unlikely to see deployment in our >> life times. Using vender assigned certs is a much more >> reasonable idea, but it suffers from the flea market problem. >> > > this referred primarily to a non-end user that requests the mapping. > furthermore, i would like to mention our discussion at the ietf#63 > geopriv meeting when we spoke about the ability to prevent denial > of service attack and the usage of end-to-end security using > special client side certificates was seen as a potential way to > address some of the problems (note that credentials that are > different to the credentials used for service access or network > access). Certs assigned to end users is wishful thinking. Certs assigned to vendors can be deployed, but it is as useful as knowing the vendor of an ethernet card (i.e. not very useful). Certs assigned to ISPs/IAPs is probably more doable depending on the will of the jurisdiction. >> From Section 5.7 >> >>> However, even if the AIP or ISP provides a signed location, it is >>> difficult to ensure that such a signed location object is only >>> used >>> for calls from that location, as it will have to be copied from a >>> location delivery protocol to the call signaling protocol. For >>> example, a third party could obtain such a signed location >>> object and >>> use it elsewhere. Naturally, timestamps will restrict such >>> useage to >>> the order of minutes or hours, depending on how often location >>> information is updated. >>> >> Wouldn't including the IP address in the signed data stop the >> location object from having validity outside the AIP/ISP network? >> > including the ip address in the signed information blob might work > in some areas but it does not work if you are in a network that > uses a private address space. I would assume the IP address or IP subnet would be the one the ISP uses to communicate over the Internet. If they don't have one, then their problem is out of scope. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Oct 29 16:27:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVxIg-000452-Mv; Sat, 29 Oct 2005 16:27:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVxIf-00044x-A6 for ecrit@megatron.ietf.org; Sat, 29 Oct 2005 16:27:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23130 for ; Sat, 29 Oct 2005 16:27:18 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVxWU-0006dt-J5 for ecrit@ietf.org; Sat, 29 Oct 2005 16:41:55 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 29 Oct 2005 13:27:27 -0700 X-IronPort-AV: i="3.97,266,1125903600"; d="scan'208"; a="225298849:sNHT28254944" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j9TKRK8k024846 for ; Sat, 29 Oct 2005 13:27:20 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 29 Oct 2005 13:27:24 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.83.77]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 29 Oct 2005 13:27:24 -0700 Message-Id: <4.3.2.7.2.20051029152553.03d50c28@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 29 Oct 2005 15:27:23 -0500 To: "'ecrit@ietf.org'" From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 29 Oct 2005 20:27:24.0735 (UTC) FILETIME=[2C2804F0:01C5DCC7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Ecrit] draft-polk-newton-ecrit-arch-considerations-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org All Andy and I have updated our ECRIT Architecture Considerations ID here: http://www.ietf.org/internet-drafts/draft-polk-newton-ecrit-arch-considerations-01.txt Comments are requested cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Oct 30 15:03:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWJNb-0003Fh-SP; Sun, 30 Oct 2005 15:02:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWJNY-0003Ay-O7 for ecrit@megatron.ietf.org; Sun, 30 Oct 2005 15:02:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14976 for ; Sun, 30 Oct 2005 15:01:46 -0500 (EST) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWJNp-0007aV-EI for ecrit@ietf.org; Sun, 30 Oct 2005 15:02:26 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j9UJljRp018323 for ; Sun, 30 Oct 2005 20:47:45 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j9UJlh70007231 for ; Sun, 30 Oct 2005 20:47:45 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Sun, 30 Oct 2005 20:47:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sun, 30 Oct 2005 20:47:43 +0100 Message-ID: Thread-Topic: meeging agenda Thread-Index: AcXdfIoBJVtSIvPyQNC5HKdZQLZluA== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 30 Oct 2005 19:47:44.0118 (UTC) FILETIME=[CB9C7160:01C5DD8A] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] meeging agenda X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all,=20 here is the proposed agenda for the meeting. the main goal for this meeting is to make progress on the requirements in order to start with the protocol work. i expect everyone to read the documents and to focus on the open issues.=20 -------------------- Emergency Context Resolution with Internet Technologies WG MONDAY, November 7, 2005 1300-1500 Afternoon Session I =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D CHAIRS:=20 Hannes Tschofenig Marc Linsner AGENDA o Agenda Bashing / Current Status (Chairs, 15 min) o Open Issues in the Requirements (75 min)=20 =20 - Open Issues in the Requirements Document (Roger Marshall) =20 http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-requirements -01.txt - Open Issues in the Security Threats Document (Tom Taylor) =20 http://www.ietf.org/internet-drafts/draft-taylor-ecrit-security-threats- 00.txt =20 - Issues raised by the Architectural Considerations Document (Andrew Newton/James Polk) =20 http://www.ietf.org/internet-drafts/draft-polk-newton-ecrit-arch-conside rations-01.txt - Impact of the Location-to-URL Mapping Architecture (Henning Schulzrinne) =20 http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-mapping-arch -00.txt o Emergency Services URI (Henning Schulzrinne, 15 min) =20 http://www.ietf.org/internet-drafts/draft-schulzrinne-sipping-service-00 .txt http://www.ietf.org/internet-drafts/draft-ietf-sipping-sos-01.txt o Next Steps (Chairs, 15 min) -------------------- ciao hannes & marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit