From ecrit-bounces@ietf.org Fri Jul 01 00:29:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoD9f-0000q2-1t; Fri, 01 Jul 2005 00:29:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoD9d-0000pu-2C for ecrit@megatron.ietf.org; Fri, 01 Jul 2005 00:29:29 -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 AAA11736 for ; Fri, 1 Jul 2005 00:29:26 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoDZV-0005JK-Hw for ecrit@ietf.org; Fri, 01 Jul 2005 00:56:14 -0400 Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 01 Jul 2005 00:29:23 -0400 id 001502EC.42C4C6A4.00002E91 In-Reply-To: <42C4B3EE.3020400@cs.columbia.edu> References: <8C837214C95C864C9F34F3635C2A65750297F463@SEA-EXCHVS-2.telecomsys.com> <42C44CB8.5070106@cs.columbia.edu> <42C4520E.8010707@cs.columbia.edu> <42C45858.5000301@cs.columbia.edu> <42C46523.6070603@cs.columbia.edu> <42C46D20.5080301@cs.columbia.edu> <42C4B3EE.3020400@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <68737CB5-BF0E-47F4-8F96-7F87DD878300@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] R5 Date: Fri, 1 Jul 2005 00:29:21 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 Jun 30, 2005, at 11:09 PM, Henning Schulzrinne wrote: > Thus, even if every Verizon POP in the US had cached the complete > address table for the US, storage is going to be a trivial expense. I suppose things like indexes and all those nice little data management bits come from free on the disks you buy? I have a SleepyCat database of 4 million IPs sitting on my disk. Using your guidelines, the database size should only be 20 meg ( (4 bytes for IPv4 key + 1 byte of value) * 4m ). Yet, it appears to be 448 meg. There is more to data management than the size of the record. > Clearly, caches have timeouts and need to be updated, but very > slowly, since address-to-PSAP mappings don't change very frequently. This is the real problem. How slowly? How often is an emergency call made from every address, or even from most addresses? If the TTL is set to 5 years, that means changes in the mapping must wait 5 years to fully propagate. If the TTL is 6 months, won't most entries expire out of the cache? >> At the interim meeting, Marc told me of a state where they did >> not want the information to be widely distributed below the state >> level. >> > > I'm sorry to say that the basic design of ECRIT makes hiding such > information difficult, caching or not. Since doing the lookup does > not require to actually place a 911 call, I can easily do mappings > from any address I care to, at my leisure. I don't have to test all > addresses, just a few to get a very good idea whether, say, my > local PSAP serves the county or just one community. You are right for civic addresses, but for coordinates the guessing game could be quite lengthy. But you've assumed a system where the client runs the actual geographic mapping algorithm and not the server. If that is how it is to be, then I'm fine with that... so long as everybody knows that is a requirement (in other words, it needs to be explicit in the requirements document). -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 01 08:25:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoKa6-0005Ic-Me; Fri, 01 Jul 2005 08:25:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoKa5-0005IX-4N for ecrit@megatron.ietf.org; Fri, 01 Jul 2005 08:25: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 IAA15747 for ; Fri, 1 Jul 2005 08:25:13 -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.33) id 1DoKzz-0007Dx-UY for ecrit@ietf.org; Fri, 01 Jul 2005 08:52:07 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 01 Jul 2005 05:25:05 -0700 X-IronPort-AV: i="3.93,250,1115017200"; d="scan'208"; a="285002585:sNHT31499524" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j61COxoj006361; Fri, 1 Jul 2005 05:24:59 -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); Fri, 1 Jul 2005 05:25:03 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Jul 2005 05:25:02 -0700 From: "Marc Linsner" To: "'Henning Schulzrinne'" , "'Andrew Newton'" Subject: RE: [Ecrit] R5 Date: Fri, 1 Jul 2005 08:24: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.2600.0000 Thread-Index: AcV96u/dKSV4dj0WT9aUrmHzm2MxFQAS2QEg In-Reply-To: <42C4B3EE.3020400@cs.columbia.edu> Message-ID: X-OriginalArrivalTime: 01 Jul 2005 12:25:03.0002 (UTC) FILETIME=[E7F807A0:01C57E37] X-Spam-Score: 1.1 (+) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 --snip-- > > > > > At the interim meeting, Marc told me of a state where they > did not want > > the information to be widely distributed below the state level. > > I'm sorry to say that the basic design of ECRIT makes hiding such > information difficult, caching or not. Since doing the lookup > does not > require to actually place a 911 call, I can easily do > mappings from any > address I care to, at my leisure. I don't have to test all addresses, > just a few to get a very good idea whether, say, my local PSAP serves > the county or just one community. > --snip-- The meaning of my above statement was that local PSAPs *could* hide behind a state level infrastructure (a few have expressed a desire for this), implying a possible double ecrit/routing mechanism. First level would be visible to the Internet and supply course-grain routing to a state level B2BUA which would perform second level routing to the individual PSAP via a 'private' IP network. In this case, it would be difficult to discover individual PSAP jurisdictions. Obviously, you can replace 'state' with any other political level of choice. -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 01 09:11:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoLIj-0000as-Qd; Fri, 01 Jul 2005 09:11:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoLIf-0000aX-A5 for ecrit@megatron.ietf.org; Fri, 01 Jul 2005 09:11: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 JAA21102 for ; Fri, 1 Jul 2005 09:11:17 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoLic-0000sp-F9 for ecrit@ietf.org; Fri, 01 Jul 2005 09:38:11 -0400 Received: from [192.168.0.31] (pool-141-153-166-25.mad.east.verizon.net [141.153.166.25]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j61DBB7L008369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Jul 2005 09:11:15 -0400 (EDT) Message-ID: <42C540D5.9060208@cs.columbia.edu> Date: Fri, 01 Jul 2005 09:10:45 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marc Linsner Subject: Re: [Ecrit] R5 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: d6b246023072368de71562c0ab503126 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 tried to hint at that in other parts of the response, but multi-stage routing has indeed been my understanding. Just that my responses are already too long to begin with... Maybe there's a requirement lurking here as well. > > The meaning of my above statement was that local PSAPs *could* hide behind a > state level infrastructure (a few have expressed a desire for this), > implying a possible double ecrit/routing mechanism. First level would be > visible to the Internet and supply course-grain routing to a state level > B2BUA which would perform second level routing to the individual PSAP via a > 'private' IP network. In this case, it would be difficult to discover > individual PSAP jurisdictions. Obviously, you can replace 'state' with any > other political level of choice. > > -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 01 13:17:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoP8Y-0003tS-E5; Fri, 01 Jul 2005 13:17:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoP8W-0003sX-SH for ecrit@megatron.ietf.org; Fri, 01 Jul 2005 13:17: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 NAA16806 for ; Fri, 1 Jul 2005 13:17:05 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoPYV-00079W-5K for ecrit@ietf.org; Fri, 01 Jul 2005 13:44:01 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 01 Jul 2005 10:16:57 -0700 X-IronPort-AV: i="3.93,250,1115017200"; d="scan'208"; a="195884131:sNHT28386148" 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 j61HFtcB011083; Fri, 1 Jul 2005 13:16: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); Fri, 1 Jul 2005 13:16:50 -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] R5 Date: Fri, 1 Jul 2005 13:16:54 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E34EC18E@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] R5 Thread-Index: AcV+PowIm8hyd3GST9yrHtDD8GbdQQAISACA From: "Michael Hammer \(mhammer\)" To: "Henning Schulzrinne" , "Marc Linsner \(mlinsner\)" X-OriginalArrivalTime: 01 Jul 2005 17:16:50.0722 (UTC) FILETIME=[AB621820:01C57E60] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 So, in summary, the requirement is the ability,=20 given a working IP infrastructure and=20 a partial or full failure of the service provider application infrastructure,=20 to route a call directly from the emergency caller=20 Directly to the PSAP or a front-end state (or other political level) proxy for the PSAP,=20 aided by some type of Internet connected ALI/MSAG database=20 that enables the caller's endpoint to discover that PSAP/proxy address? Did I decipher this thread correctly? Mike > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Henning Schulzrinne > Sent: Friday, July 01, 2005 9:11 AM > To: Marc Linsner (mlinsner) > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] R5 >=20 > I tried to hint at that in other parts of the response, but=20 > multi-stage routing has indeed been my understanding. Just=20 > that my responses are already too long to begin with... >=20 > Maybe there's a requirement lurking here as well. >=20 >=20 > >=20 > > The meaning of my above statement was that local PSAPs *could* hide=20 > > behind a state level infrastructure (a few have expressed a=20 > desire for=20 > > this), implying a possible double ecrit/routing mechanism. First=20 > > level would be visible to the Internet and supply=20 > course-grain routing=20 > > to a state level B2BUA which would perform second level=20 > routing to the=20 > > individual PSAP via a 'private' IP network. In this case,=20 > it would be=20 > > difficult to discover individual PSAP jurisdictions. =20 > Obviously, you=20 > > can replace 'state' with any other political level of choice. > >=20 > > -Marc- >=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 Fri Jul 01 13:34:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoPPk-0000Fc-Ka; Fri, 01 Jul 2005 13:34:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoPPi-0000CY-W7 for ecrit@megatron.ietf.org; Fri, 01 Jul 2005 13:34: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 NAA19458 for ; Fri, 1 Jul 2005 13:34:51 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoPpj-0000JY-AL for ecrit@ietf.org; Fri, 01 Jul 2005 14:01:47 -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 j61HYmmD014924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Jul 2005 13:34:50 -0400 (EDT) Message-ID: <42C57EB3.3050600@cs.columbia.edu> Date: Fri, 01 Jul 2005 13:34:43 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] R5 References: <8C837214C95C864C9F34F3635C2A65750297F463@SEA-EXCHVS-2.telecomsys.com> <42C44CB8.5070106@cs.columbia.edu> <42C4520E.8010707@cs.columbia.edu> <42C45858.5000301@cs.columbia.edu> <42C46523.6070603@cs.columbia.edu> <42C46D20.5080301@cs.columbia.edu> <42C4B3EE.3020400@cs.columbia.edu> <68737CB5-BF0E-47F4-8F96-7F87DD878300@hxr.us> In-Reply-To: <68737CB5-BF0E-47F4-8F96-7F87DD878300@hxr.us> 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_PHRASE_7 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 suppose things like indexes and all those nice little data management > bits come from free on the disks you buy? I have a SleepyCat database > of 4 million IPs sitting on my disk. Using your guidelines, the > database size should only be 20 meg ( (4 bytes for IPv4 key + 1 byte of > value) * 4m ). Yet, it appears to be 448 meg. > > There is more to data management than the size of the record. I wasn't trying to design the database on the mailing list, as this will strongly depend on the particular implementation. I had deliberately used very large, round values to cover the variability in implementation. Are you disputing that even a national database, index and all, could easily fit on a modern disk costing ~$100? Just for fun, I checked a large SQL database I run: 104,373,568 bytes data; 93,603,840 bytes index. > >> Clearly, caches have timeouts and need to be updated, but very >> slowly, since address-to-PSAP mappings don't change very frequently. > > > This is the real problem. How slowly? How often is an emergency call > made from every address, or even from most addresses? If the TTL is > set to 5 years, that means changes in the mapping must wait 5 years to > fully propagate. If the TTL is 6 months, won't most entries expire out > of the cache? My caching model is different. If you can, you ask for the current information. If you can't (because you can't reach the server) you may use somewhat stale information since the alternative is no service at all and the likelihood of invalidation is low. The period of outages you need to "hide" with caching is probably measured in a few days (think flooding and hurricanes that interrupt wide-area access), not months. As I said before, there is no need to have emergency calls be made from each address for this to work. Address verification and testing, things we agreed on as being valuable, will fill the cache. (Just because somebody won't *require* address verification to use the service, it is still prudent to make sure that the location information you have can be resolved to an emergency-answering URL before an actual emergency call.) > You are right for civic addresses, but for coordinates the guessing > game could be quite lengthy. I'm not sure I understand. Most PSAP service boundaries follow state, county or city boundaries. Such boundaries are publicly documented and available for free from various electronic and paper sources. Why would this be harder for geo coordinates? > > But you've assumed a system where the client runs the actual geographic > mapping algorithm and not the server. Not really. I'm assuming that the "local" mapping server contacted by the client (end system or outbound proxy, say) maintains a set of boundary polygons that are of local interest. To make this concrete: Assume that Verizon in NJ offers Internet services and also offers ECRIT mapping services to its subscribers; the ECRIT server would be located in the same POP they house their DNS and DHCP servers. That server would cache a few hundred polygons for the service areas of NJ PSAPs. If Vonage, say, were to offer such an ECRIT mapping service, they may need to cache 6000 polygons, since their service footprint is national rather than regional. > If that is how it is to be, then I'm fine with that... so long as > everybody knows that is a requirement (in other words, it needs to be > explicit in the requirements document). > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 01 13:43:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoPXj-0004QS-S0; Fri, 01 Jul 2005 13:43:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoPXh-0004Q9-N9 for ecrit@megatron.ietf.org; Fri, 01 Jul 2005 13:43: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 NAA20477 for ; Fri, 1 Jul 2005 13:43:06 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoPxg-0001OL-Bj for ecrit@ietf.org; Fri, 01 Jul 2005 14:10:02 -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 j61HermD015228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Jul 2005 13:40:53 -0400 (EDT) Message-ID: <42C58020.40201@cs.columbia.edu> Date: Fri, 01 Jul 2005 13:40: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: "Michael Hammer (mhammer)" Subject: Re: [Ecrit] R5 References: <072C5B76F7CEAB488172C6F64B30B5E34EC18E@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E34EC18E@xmb-rtp-20b.amer.cisco.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' X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Roughly, although I wouldn't introduce the MSAG/ALI terminology here, since these play somewhat different roles. (One could look at ECRIT combining the functions of the two into one, but I'm not sure how helpful this analogy is; it seems more likely to introduce assumptions that we'd probably rather not. Just as a "for example", there is very little electronic linkage between MSAGs.) Michael Hammer (mhammer) wrote: > So, in summary, the requirement is the ability, > given a working IP infrastructure and working in the sense that I can place a SIP (H.323, whatever) call to the PSAP; not necessarily in that I can reach some random server anywhere else. > a partial or full failure of the service provider application > infrastructure, > to route a call directly from the emergency caller > Directly to the PSAP or a front-end state (or other political level) > proxy for the PSAP, > aided by some type of Internet connected ALI/MSAG database > that enables the caller's endpoint to discover that PSAP/proxy address? > > Did I decipher this thread correctly? > > Mike > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 01 13:58:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoPmO-0006Kq-2B; Fri, 01 Jul 2005 13:58:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoPmM-0006Jl-LY for ecrit@megatron.ietf.org; Fri, 01 Jul 2005 13:58: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 NAA22769 for ; Fri, 1 Jul 2005 13:58:15 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoQCK-0002JC-2T for ecrit@ietf.org; Fri, 01 Jul 2005 14:25:11 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 01 Jul 2005 10:58:05 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j61Hw2of000223; Fri, 1 Jul 2005 10:58:02 -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); Fri, 1 Jul 2005 13:58:04 -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] R5 Date: Fri, 1 Jul 2005 13:58:03 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E34EC1A9@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] R5 Thread-Index: AcV+ZGK9FzrJms24QdWhDBOvR+fb+AAAJaZw From: "Michael Hammer \(mhammer\)" To: "Henning Schulzrinne" X-OriginalArrivalTime: 01 Jul 2005 17:58:04.0137 (UTC) FILETIME=[6DA74590:01C57E66] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 didn't mean to imply exact functionality, just the ability to determine a PSAP address from the user's current number or location. =20 E.164-->civil address-->PSAP address (jurisdiction) (fixed) | ^ ^ | | | v | | Location---+----------+ (mobile) Understood that such P2P calls are supported for E911 only. Anything else is out of scope. Mike =20 > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 > Sent: Friday, July 01, 2005 1:41 PM > To: Michael Hammer (mhammer) > Cc: Marc Linsner (mlinsner); ecrit@ietf.org > Subject: Re: [Ecrit] R5 >=20 > Roughly, although I wouldn't introduce the MSAG/ALI=20 > terminology here, since these play somewhat different roles.=20 > (One could look at ECRIT combining the functions of the two=20 > into one, but I'm not sure how helpful this analogy is; it=20 > seems more likely to introduce assumptions that we'd probably=20 > rather not. Just as a "for example", there is very little=20 > electronic linkage between MSAGs.) >=20 > Michael Hammer (mhammer) wrote: > > So, in summary, the requirement is the ability, given a working IP=20 > > infrastructure and >=20 > working in the sense that I can place a SIP (H.323, whatever)=20 > call to the PSAP; not necessarily in that I can reach some=20 > random server anywhere else. >=20 >=20 > > a partial or full failure of the service provider application=20 > > infrastructure, to route a call directly from the emergency caller=20 > > Directly to the PSAP or a front-end state (or other=20 > political level)=20 > > proxy for the PSAP, aided by some type of Internet=20 > connected ALI/MSAG=20 > > database that enables the caller's endpoint to discover that=20 > > PSAP/proxy address? > >=20 > > Did I decipher this thread correctly? > >=20 > > Mike > >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 01 14: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 1DoQ2I-0001RM-9Q; Fri, 01 Jul 2005 14: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 1DoQ2H-0001RH-8C for ecrit@megatron.ietf.org; Fri, 01 Jul 2005 14:14: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 OAA24719 for ; Fri, 1 Jul 2005 14:14:41 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoQSH-00033F-7H for ecrit@ietf.org; Fri, 01 Jul 2005 14:41:38 -0400 Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 01 Jul 2005 14:14:40 -0400 id 00213C39.42C58810.0000051E In-Reply-To: <42C57EB3.3050600@cs.columbia.edu> References: <8C837214C95C864C9F34F3635C2A65750297F463@SEA-EXCHVS-2.telecomsys.com> <42C44CB8.5070106@cs.columbia.edu> <42C4520E.8010707@cs.columbia.edu> <42C45858.5000301@cs.columbia.edu> <42C46523.6070603@cs.columbia.edu> <42C46D20.5080301@cs.columbia.edu> <42C4B3EE.3020400@cs.columbia.edu> <68737CB5-BF0E-47F4-8F96-7F87DD878300@hxr.us> <42C57EB3.3050600@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0FF0418D-EDFF-4F14-A1A4-8CD1E0B05274@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] R5 Date: Fri, 1 Jul 2005 14:14:36 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 Jul 1, 2005, at 1:34 PM, Henning Schulzrinne wrote: > My caching model is different. If you can, you ask for the current > information. If you can't (because you can't reach the server) you > may use somewhat stale information since the alternative is no > service at all and the likelihood of invalidation is low. So for the normal use case, you have added latency and inserted a single point of failure. Seeing that there are many different caching methods, database replication methods, and fault-tolerant architectures that could address this problem, I think this is out of scope for defining the query interface that a client is to use as any number of these things could be used. This does seem like a deployment consideration, but not a protocol requirement. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 01 15:30:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoRDw-0002AC-8X; Fri, 01 Jul 2005 15:30:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoRDu-00022n-Sw for ecrit@megatron.ietf.org; Fri, 01 Jul 2005 15:30: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 PAA03127 for ; Fri, 1 Jul 2005 15:30:46 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoRdu-0007gW-Bx for ecrit@ietf.org; Fri, 01 Jul 2005 15:57:44 -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 j61JUhmD021414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Jul 2005 15:30:44 -0400 (EDT) Message-ID: <42C599DE.3000400@cs.columbia.edu> Date: Fri, 01 Jul 2005 15:30: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: Andrew Newton Subject: Re: [Ecrit] R5 References: <8C837214C95C864C9F34F3635C2A65750297F463@SEA-EXCHVS-2.telecomsys.com> <42C44CB8.5070106@cs.columbia.edu> <42C4520E.8010707@cs.columbia.edu> <42C45858.5000301@cs.columbia.edu> <42C46523.6070603@cs.columbia.edu> <42C46D20.5080301@cs.columbia.edu> <42C4B3EE.3020400@cs.columbia.edu> <68737CB5-BF0E-47F4-8F96-7F87DD878300@hxr.us> <42C57EB3.3050600@cs.columbia.edu> <0FF0418D-EDFF-4F14-A1A4-8CD1E0B05274@hxr.us> In-Reply-To: <0FF0418D-EDFF-4F14-A1A4-8CD1E0B05274@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 Andrew Newton wrote: > > On Jul 1, 2005, at 1:34 PM, Henning Schulzrinne wrote: > >> My caching model is different. If you can, you ask for the current >> information. If you can't (because you can't reach the server) you >> may use somewhat stale information since the alternative is no >> service at all and the likelihood of invalidation is low. > > > So for the normal use case, you have added latency and inserted a > single point of failure. We're obviously not communicating. For the "normal" case, you can either rely on locally cached data (if available and fresh) or go ask the authoritative source. There's a trade-off you can't avoid: asking on demand takes time, but you can change the data on a minute-by-minute basis. The protocol needs to allow operators to tune the fresh vs. fast button. This has nothing to do with single points of failure. > > Seeing that there are many different caching methods, database > replication methods, and fault-tolerant architectures that could > address this problem, I think this is out of scope for defining the > query interface that a client is to use as any number of these things > could be used. This does seem like a deployment consideration, but not > a protocol requirement. Without caching and synchronization support in the protocol, you'll have the problems we discussed earlier, so this is more than a deployment issue. As a slightly related example: DNS specifies zone transfer and caching, but there are obviously many different deployment architectures for DNS. Without the two functions, however, we would only be able to deploy closed DNS systems where the reliability is magic hidden behind some proprietary interface. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 01 15:51:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoRXi-00029k-NY; Fri, 01 Jul 2005 15:51:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoRXh-00022f-AG for ecrit@megatron.ietf.org; Fri, 01 Jul 2005 15:51: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 PAA05461 for ; Fri, 1 Jul 2005 15:51:15 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoRxf-0001Zn-KP for ecrit@ietf.org; Fri, 01 Jul 2005 16:18:11 -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 j61Jou97009831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 1 Jul 2005 12:50:56 -0700 (PDT) Received: from [192.168.1.4] (carbuncle.qualcomm.com [129.46.227.161]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j61JosTT014929 for ; Fri, 1 Jul 2005 12:50:55 -0700 (PDT) Mime-Version: 1.0 Message-Id: Date: Fri, 1 Jul 2005 12:50:53 -0700 To: ecrit@ietf.org From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Ecrit] simplified R5? 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 beginning to strongly suspect that part of R5 belongs in the implementation and deployment docs, rather than as a protocol requirement. Going through Henning's scenario (in which the fresh data is first checked, but the local copy is available), I realized that we could run that exact scenario in reverse--the local copy is not available, but the "parent" copy is available by some onerous network path. Checking the local copy first might be sensible in some network topologies, and preferring one over the other seems problematic. That led me to a far simpler protocol requirement--the the protocol must be able to support topologically distinct redundant servers. Whether these get updated via pull-based caching, a replication process, or the seasonal migration of avian carriers doesn't really enter into what the client needs to do--- check a second identified server if the first one craps out. For the current work of ECRIT, this seems in scope, where some elements of the other discussion look out of scope. Also, I really fear that R5 as discussed (though possibly not as written) implies that the infrastructure for mapping be maintained by the access provider, even though the voice services provider 1) is responsible for delivering the call, 2) must be up and available to do so, and 3) has a business reason to do so (the other is an "unfunded mandate" that regulation might achieve but the market will resist). That may be a common thing, but I believe we have to support scenarios where it isn't the way the deployment works. As a proposal, I'd like to suggest we scrap R5 as written, replace it with "the protocol must support topologically distinct redundant servers", and discuss the good ways of achieving that in the deployment doc. regards, Ted Hardie _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 01 16:52:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoSUo-0002x3-O3; Fri, 01 Jul 2005 16:52:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoSUk-0002l7-8f for ecrit@megatron.ietf.org; Fri, 01 Jul 2005 16:52: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 QAA20939 for ; Fri, 1 Jul 2005 16:52:15 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoSul-0003Gj-FK for ecrit@ietf.org; Fri, 01 Jul 2005 17:19:12 -0400 Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 01 Jul 2005 16:52:12 -0400 id 00213C3E.42C5ACFC.0000243E In-Reply-To: <42C599DE.3000400@cs.columbia.edu> References: <8C837214C95C864C9F34F3635C2A65750297F463@SEA-EXCHVS-2.telecomsys.com> <42C44CB8.5070106@cs.columbia.edu> <42C4520E.8010707@cs.columbia.edu> <42C45858.5000301@cs.columbia.edu> <42C46523.6070603@cs.columbia.edu> <42C46D20.5080301@cs.columbia.edu> <42C4B3EE.3020400@cs.columbia.edu> <68737CB5-BF0E-47F4-8F96-7F87DD878300@hxr.us> <42C57EB3.3050600@cs.columbia.edu> <0FF0418D-EDFF-4F14-A1A4-8CD1E0B05274@hxr.us> <42C599DE.3000400@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] R5 Date: Fri, 1 Jul 2005 16:52:08 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 Jul 1, 2005, at 3:30 PM, Henning Schulzrinne wrote: > This has nothing to do with single points of failure. The box you are insisting on putting between the client and the mapping service is a single point of failure. > Without caching and synchronization support in the protocol, you'll > have the problems we discussed earlier, so this is more than a > deployment issue. As a slightly related example: DNS specifies zone > transfer and caching, but there are obviously many different > deployment architectures for DNS. Without the two functions, > however, we would only be able to deploy closed DNS systems where > the reliability is magic hidden behind some proprietary interface. First, zone transfers in DNS are not related to answering normal DNS queries such as converting a domain name to an IP address. In fact, most DNS administrators either turn it off or severely restrict to whom it will answer. None of the name servers my company run get their data via zone transfer, yet we answer a lot of DNS queries every second. Second, the caching you describe does not sound like DNS caching. DNS caches usually do not contain ALL the data from ALL the authoritative servers they talk to. And they generally don't query the authoritative servers upon a cache hit just to see if the data has changed. What you have been describing is not a cache like what we have with DNS. You are describing some form of database replication. How that database replication works does not need to be mixed in with the protocol used by the client to do a location-to-uri mapping query. Those are two different functions. You stated earlier in this thread that "caching" is one of many ways to meet your suggested requirement. If there are multiple ways, does the client query interface have to support them all? I doubt it. You can still do your database replication without putting that in the query interface. That is why this is out of scope. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 01 16:58:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoSah-0003dT-U6; Fri, 01 Jul 2005 16:58:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoSaf-0003Sp-4m for ecrit@megatron.ietf.org; Fri, 01 Jul 2005 16:58: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 QAA21534 for ; Fri, 1 Jul 2005 16:58: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.33) id 1DoT0g-00042F-Ey for ecrit@ietf.org; Fri, 01 Jul 2005 17:25:19 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 01 Jul 2005 13:58:14 -0700 X-IronPort-AV: i="3.93,251,1115017200"; d="scan'208"; a="646844905:sNHT27665364" 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 j61KvsVn023923 for ; Fri, 1 Jul 2005 13:58:12 -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); Fri, 1 Jul 2005 13:58:11 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Jul 2005 13:58:11 -0700 From: "Marc Linsner" To: Date: Fri, 1 Jul 2005 16:58:07 -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.2600.0000 Thread-Index: AcV+f5Iz4T0CQmwlQ2qFCll13R5x8w== Message-ID: X-OriginalArrivalTime: 01 Jul 2005 20:58:11.0308 (UTC) FILETIME=[973AB2C0:01C57E7F] X-Spam-Score: 1.1 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Subject: [Ecrit] D5 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 Call setup latency: The ECRIT mechanism MUST minimize the added call setup time such that the user experience does not perceive abnormal delay. Motivation: The additional properties of emergency calling include the need to route the call based on the user location. It is possible that the ECRIT mechanism will add to the call setup time when compared to non-emergency call setup latency. PSTN experience has shown that the end user will abandon a call setup if they perceive that the call setup is not progressing in timely manner. This action is exacerbated when a user is dealing with an emergency situation. If the ECRIT mechanism increases call setup times by factors of 1.5 or more, the user experience may be impacted such that calls are abandoned prematurely. Although hard numbers are not offered, the user should perceive no additional call setup time when using the ECRIT mechanism compared to establishing non-emergency calls. -Marc- Marc Linsner Consulting Engineer - Corporate Development Cisco Systems, Inc. +1-239-272-2105 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 01 18:39:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoUAJ-0005RC-Gg; Fri, 01 Jul 2005 18:39:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoUAF-0005R5-Vw for ecrit@megatron.ietf.org; Fri, 01 Jul 2005 18:39: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 SAA02425 for ; Fri, 1 Jul 2005 18:39:12 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoUaH-00071f-0m for ecrit@ietf.org; Fri, 01 Jul 2005 19:06:11 -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, 1 Jul 2005 18:38: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] (114) Comments on ECRIT Reqs ID Date: Fri, 1 Jul 2005 15:38:56 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A6575029B5234@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] (114) Comments on ECRIT Reqs ID Thread-Index: AcVZjuhiT+bkGXmHQImpylVqFr6+QAk/dmPw From: "Roger Marshall" To: "James M. Polk" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 738f70ed28a216241b56e64627db3306 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 Hello: Below is a follow-up to James' (114!) list of comments to ecrit requirements I-D back on 5/14. We talked about this at the interim meeting, but since there were some straightforward changes that I didn't want to lose, I have gone through individually and made changes to the I-D as noted (grammatical, etc.). For other comments, they're either moot, due to deletes/moves, or have suggestions to push to the ecrit list for resolution, (also noted). My responses in-line within [brackets]. Roger Marshall -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of James M. Polk Sent: Saturday, May 14, 2005 7:01 PM To: ecrit@ietf.org Subject: [Ecrit] (114) Comments on ECRIT Reqs ID All I reviewed the requirements ID draft-schulzrinne-ecrit-requirements-00.txt=20 for the meeting this coming week, and have a few comments.... ok, 114=20 comments.... listed.... below.... For those of you attending the interim, I will bring these up there. For those of you not attending the interim, chime in and be heard about this comments. My overall comment to this ID is it is taking on waaaaaay more than the WG=20 charter intended, but I am not surprised. I know a lot of folks want to get=20 specific items addressed here. Some of those items I feel should be=20 addressed elsewhere. Anyway, to the comments - here they are in the order they appear in the doc=20 with one exception, the last one. The last one should be addressed=20 somewhere, and I do not know if it should only be addressed in http://www.ietf.org/internet-drafts/draft-ietf-sipping-location-requirem ents-02.txt=20 and its next version in the SIP WG. The comments: [note to ID authors - I know this is a group effort, so do not take my use=20 of the word "you" personally] The following is a review of draft-schulzrinne-ecrit-requirements-00 on May=20 14th, 2005 Comment #1 Section 2 - Terminology - top paragraph "MUSTNOT", "SHALLNOT", "SHOULDNOT" are all 2 words each [RM - Changed in I-D] Comment #2 Section 2 - Terminology - 2nd paragraph "protocols" should be singular [RM - Changed in I-D] Comment #3 Section 2 - Terminology - term When did IAP become AIP? IAP and ISP flowed and should be retained. [interim_mtg_1 Based on a hum, the IAP term won - will through it out to the list /] [RM - take to the list (I haven't seen this resolved)] Comment #4 Section 2 - Terminology - term basic emergency service - should be capitalized [RM - Changed in I-D] Comment #5 Section 2 - Terminology - term "domain" should be renamed "administrative domain" [interim_mtg_2 /] [RM - Changed in I-D and reordered, though this term is not used in the current I-D] Comment #6 Section 2 - Terminology - term You mention "IPSAP" before defining it, and don't state you will define it=20 below like you do other terms. Some call this an IP-PSAP, not an IPSAP, BTW... [RM - Changed all "iPSAP" reference to PSAP as agreed to at interim meeting] Comment #7 Section 2 - Terminology - term emergency caller: The user or user device entity needing sending his/ her location to another entity in the network. "...needing sending..." is poor wording [RM - Change from "needing sending" to "which sends", though this now should be sent to the list based on next comment] Comment #8 Section 2 - Terminology - term emergency caller: The user or user device entity needing sending his/ her location to another entity in the network. The "emergency caller" is "the individual in distress desiring help". [RM - send to the list, since it may better be termed "initiates request for help, rather than "sends location", etc.] Comment #9 Section 2 - Terminology - term geographic coordinate system - you fail to mention "a defined meridian", which should be added to the definition [RM - take to the list (definition as stated taken from www.esri.com/library/glossary/glossary.html which most edu's reference as well)] Comment #10 R2. International: The protocols and protocol extensions developed MUST support regional, political and organizational differences. Motivation: It must be possible for a device or software developed... This "must" in the motivation should be a MUST as it talks normatively [ /] [RM - Changed "must" to "MUST"] Comment #11 R5. Minimum Connectivity: NEED REQUIREMENT HERE Motivation: If there is network connectivity between the emergency caller and the PSAP, and routing information is available, the call should be completed, even if other parts of the network are not reachable. This makes little sense, because if there is connectivity, there is a=20 route, yet the wording seems to believe there might not be (which means=20 there is "no connectivity") [RM - Henning has provided] Comment #12 R6. Incremental Deployment Emergency calls from IP-based devices MUST be incrementally supported. This wording doesn't make sense; should it be: "R6 Incremental Deployment - incremental deployment of IP-based=20 emergency calling MUST be supported" [RM - n/a due to rewritten R6] Comment #13 "R6 Motivation: Any mechanism must be deployable incrementally and work even if not all entities support IP-based emergency calling. For example, User agents conforming to the SIP specification [1], but unaware of this document, must be able to place emergency calls, possibly with restricted functionality." This ID professes that it all about IP e2e connectivity, yet this states it=20 isn't really necessary. Which is it? This motivation, or the wording in the Intro section? [RM - is this now n/a?] Comment #14 R7. Middlebox Reliance: For a transient time the device and the UA MAY use the help of servers (e.g. ESRP) to provide the connectivity to ECC, especially for ECC not yet connected to the Internet. Same as comment to #13 - This ID professes that it all about IP e2e=20 connectivity, yet this states it isn't really necessary. Which is it? This=20 motivation, or the wording in the Intro section? [RM - take to the list] Comment #15 R7 Motivation: Emergency calling mechanisms must support existing emergency call centers based on circuit-switched technology as well as future ECCs that are IP-enabled. This motivation statement clearly contradicts the Intro section (stating this is for IP e2e scenarios). [RM - n/a since R7 removed] Comment #16 A2. Local: Since many countries have already deployed national emergency identifiers, such as 911 in North America and 112 in large parts of Europe, UAs, proxies and call routers MUST recognize these universal emergency identifiers, but MAY NOT recognize lower level local emergency identifiers, including those such as 999, 122, 133, etc. In addition, these same call routing entities SHOULD recognize emergency identifiers that are used in other jurisdictions I don't understand this one as written, as there are ~60 different numbers=20 around the world, we should list which ones are recommended for support and=20 discuss the list. Primary examples are 115, 116, 117 etc for different emergency services=20 within the same jurisdiction. [RM - n/a since A2 removed] Comment #17 A2. Local - [Ed. The requirement A2 is really a set of 3 requirements, and needs to have the question answered which is: "what does the term "local" mean?".] Good question... [RM - n/a] Comment #18 A2 Motivation: The latter requirement is meant to help travelers that may not know the local emergency number and instinctively dial the number they are used to from home. However, it is unlikely that all systems could be programmed to recognize any emergency number used anywhere as some of these numbers are used for non-emergency purposes, in particular extensions and service numbers. What is meant by this last phrase: "... in particular extensions and service numbers." [RM - n/a] Comment #19 A3. Recognizable: Emergency calls MUST be recognizable by user agents, proxies and other network elements. To prevent fraud, an address identified as an emergency number for call features or authentication override MUST also cause routing to a PSAP. Recommend replacing some of the last sentence with: "...any call recognized=20 as an emergency call MUST be delivered expeditiously to an ECC". [RM - A3 needs to be rewritten (need a volunteer)] Comment #20 A5. Secure configuration: Devices SHOULD be assured of the correctness of the local emergency numbers that are automatically configured. How do you "assure a device" without asserting something that requires a key the remote and local domains understand, as well as the UA understands? [RM - n/a since A5 removed] Comment #21 A6. Backwards-compatible: Existing devices that predate the specification of emergency call-related protocols and conventions MUST be able reach a PSAP. I've read this above somewhere else in the ID. If a PIDF-LO is required to=20 complete a 911 call, and it isn't present, and the device doesn't support=20 the error messages from draft-ietf-sipping-location-requirements-02.txt,=20 how can this work? I think this can work in residential and SMB scenarios, but I'm not sure about any others. VPNs in those other network types is but one reason for=20 these problems. [RM - to the list] Comment #22 A7. Common Identifier: User initiated requests using local initiation methods (e.g. 9-1-1) MUST be supported across non-local domains (e.g. foreign countries). This is stated too US-centric. The IETF isn't about a country. This should=20 state that all/most recognizable local emergency numbers will be converted=20 to (perhaps) one SIP user-part for all SIP intermediaries to know to=20 process accordingly. [RM - n/a since A7 removed] Comment #23 A7 Motivation: While traveling, users must be able to use their familiar "home" emergency identifier. Users should also be able to dial the local emergency number in the country they are visiting. Looking at the range of potential numbers, this will be interesting to meet=20 - including just dialing '0' and meaning an emergency call [RM - n/a since A7 removed] Comment #24 Section 5 Proxy-inserted: A proxy along the call path inserts the location or location reference. This violates 3261 and draft-ietf-sipping-location-requirements-02.txt [RM - to the list] Comment #25 L1. Multiple location services: For UA-referenced locations, PSAPs MUST be able to access different location providers. The location provider may be tied to the ASP, AIP or ISP or may be independent of these entities. This may be inside an enterprise, and that should not be underscored or=20 overlooked due to the trust-boundary issues known there [RM - n/a since L1 was removed] Comment #26 L1 Motivation: This requirement avoids that all users have to rely on a single location service provider. This requirement is hard to avoid if there are no traditional national application-layer service providers. I don't understand the first sentence as written, especially since this ID=20 just got done talking about internationalization scope. [RM - n/a since L1 was removed] Comment #27 L2. Civic and Geographic: Where available, both civic (street address) and geographic (longitude/latitude) information SHOULD be provided to the PSAP. This necessitates a PIDF-LO extension to indicate if one was derived from=20 the other. That XML element doesn't exist to my knowledge. [RM - n/a since L2 was removed] Comment #28 L2 Motivation: While geographic coordinate information can usually be translated into civic address location information, "some specific information, such as building number and floor, is more easily provided as civic location information since it does not require a detailed surveying operation". For direct location determination, it may also be easier for the user to check civic location information to assure verity. I don't understand the quoted comment (I put in the quotes BTW) in the=20 first sentence above. Is this suggesting a detailed survey *will* yield the=20 cube number from a GPS coordinate on a non-ground floor? If it won't, it doesn't need to be brought up as motivation. [RM - n/a since L2 was removed] Comment #29 L3. Location source identification: The source of a location data, whether measured, derived (e.g geocoding or reverse geocoding transformation), or manually input, MUST be indicated to the PSAP. How is this not covered by the element in the PIDF-LO, and if so,=20 why is the requirement not just "...the element MUST be present when known"... [RM - n/a since L3 was removed] Comment #30 L3 Motivation: This allows the PSAP to better judge the reliability and accuracy of the data and track down problems. I don't believe the word "judge" is appropriate here, as the PSAPs first need to "learn" (a better word for above) from real world experience what=20 data indicates what results. Down the road, they will then analyze trends=20 and such to determine how best to interpret data. [RM - n/a since L3 was removed] Comment #31 L4. Certifiable: In some cases, the source and generation time of the location object used for call routing and caller location display MUST be verifiable, e.g., by a digital signature. The security requirements describe this in more detail. If my wireline phone has a timestamp of 2002, is that bad/untrusted? I=20 don't believe so. This requirement needs to be adjusted to state this is a=20 function of the the location was derived from. Further, a future=20 document (perhaps years from now) needs to be generated to give=20 recommendations of those functions per value. [RM - n/a since L4 was removed] Comment #32 L5. Multiple locations: Multiple locations MAY be associated with the caller How is this requirement different that L2? If it can be different, then this text needs to state when/how it can be different, yet still be considered good. [RM - n/a since L5 was removed] Comment #33 L5 Motivation: Multiple locations may occur either because the caller has provided more than one civic or geographic (coordinates) location, supplies both civic and geospatial location information, or because different location determination entities make different assessments of the caller's location." There needs to be a requirement stating if there is location information in=20 both formats, and both are depicting the same location (as far as the UA is=20 concerned), they MUST be in the same PIDF-LO; if different - or not sure they are the same location, they need to be in separate PIDF-LOs (typically=20 with different values). [RM - n/a since L5 was removed] Comment #34 L5 Motivation: Multiple locations may occur either because the caller has provided more than one civic or geographic (coordinates) location, supplies both civic and geospatial location information, or because different location determination entities make different assessments of the caller's location." If there are more than one, and they are different, which is trusted to be=20 true? [RM - n/a since L5 was removed] Comment #35 L6. Validation of civic location: It MUST be possible to validate an address prior to its use in an actual emergency call. How is "validate" here in L6 different from "certifiable" in L4? [RM - see rewritten L6 (Nadine)] Comment #36 L6. Validation of civic location: It MUST be possible to validate an address prior to its use in an actual emergency call. "... prior to its use in an actual emergency call." should be replaced with: "at any time" only. And...it's an implementation issue when this occurs, so I'm not sure this=20 belongs in the ID. Someone like NENA should be defining this type of=20 requirement. [RM - changed "...validate an address prior to its use in an actual emergency call" to "...validate an Address at any time, including prior to its use in an actual emergency call"] Comment #37 L7. Provide location: Calls using VoIP or subsequent methods MUST supply location with the call. "... with the call" should be replaced with: "...in each Request message (if SIP is used)." [RM - n/a since L7 was removed] Comment #38 L8. Accept two location types: PSAPs shall accept location as civic and/or geo specified. [Ed. Suggest deleting above requirement since it doesn't deal with routing] I disagree with the Ed. Comment because this (as written) limits how many=20 different formats a routing Proxy forwards, and how many formats an ECC has=20 to deal with. The same piece of location information (if in a PIDF-LO) will be used for=20 routing and dispatching. Limiting the number to two here is good. [RM - n/a since L8 was removed] Comment #39 L9. Altitude included with location: All representations of location SHALL include the ability to carry altitude. This requirement does not imply altitude is always used or supplied. Either it does or it doesn't, but "include the ability..." is wishy-washy [RM - n/a see changed L9 text] Comment #40 L10. Preferred datum: The preferred geographic coordinate system for emergency calls SHALL be WGS-84. 2D or 3D? [RM - to the list] Comment #41 L11. Multiple locations: If multiple locations are provided with a call, it SHOULD be possible to identify the most accurate, current, appropriate location information to be used for routing emergency calls and dispatching emergency responders. Exactly how will this be accomplished, especially by a Proxy? This is=20 fruitless, therefore pointless. L2 should be all that is stated for this type of requirement. [RM - n/a since L11 removed] Comment #42 L14. Imprecise location: Imprecise location information MUST be available for emergency call routing and location delivery in cases where precise measurement based location determination mechanisms fail. How is "imprecise location" indicated to the PSAP as "imprecise"? If it=20 cannot be, it shouldn't be a requirement. [RM - n/a since L14 removed] Comment #43 L15. Default identification: PSAPs MUST be made aware when imprecise location information was used to route a call. Same comment here that was to L14 - How is "imprecise location" indicated=20 by the proxy to the PSAP as "imprecise"? If it cannot be, it shouldn't be a=20 requirement. [RM - n/a since L15 removed] Comment #44 L16. Location Responsibility: Location determination MUST assume a responsible party. This is begging for liability statements to be included every time a=20 location is given to a device, that it should not be used unless the user=20 agrees "not to hold the deliverer responsible" before usage. [RM - n/a since L16 removed] Comment #45 L17 Motivation: The location information MUST be attributed to a specific point in time. That is, the location used for routing and which is reported to the PSAP call taker, must be the actual location of the caller at the time of making the call. This makes learning/getting/retrieving location a real-time event as the emergency call is being initiated - and this is not practical. If my home=20 wireline phone has a timestamp of 2002, is that bad? [RM - n/a since L17 removed] Comment #46 L18. Location, Emergency Caller: Location provided with call MUST be associated with an Emergency Caller. Huh? This is to a device, one in which a user might not be logged into. [RM - n/a since L18 removed] Comment #47 L19 Motivation: Requirement 1 states that a level of authentication and validation for the source of the location is required. This implies the need to for the Emergency Caller to determine the authenticating and validating entity for the emergency services domain in which they reside. That is, it must be possible for an Emergency Caller to discover and utilize an answerable source of location in the access network they are using. The term in the 1st sentence "level" needs to be defined in order to=20 understand if it is met. Level is not currently defined within this ID. [RM - n/a since L19 removed] Comment #48 L19. Location Domain Availability: Location domain MUST be obtainable by Emergency Caller. Motivation: Requirement 1 states that a level of authentication and validation for the source of the location is required. This implies the need to for the Emergency Caller to determine the authenticating and validating entity for the emergency services domain in which they reside. That is, it must be possible for an Emergency Caller to discover and utilize an answerable source of location in the access network they are using. "Emergency Caller" as used in the 1st sentence - I personally don't care who the authority is, and I doubt most (if any) do outside of this list and=20 some regulators. [RM - n/a since L19 removed] Comment #49 L19. Location Domain Availability: Location domain MUST be obtainable by Emergency Caller. Motivation: Requirement 1 states that a level of authentication and validation for the source of the location is required. This implies the need to for the Emergency Caller to determine the authenticating and validating entity for the emergency services domain in which they reside. That is, it must be possible for an Emergency Caller to discover and utilize an answerable source of location in the access network they are using. This last sentence isn't clear. Provide an example of me discovering an=20 "answerable source" so I can visualize it. [RM - n/a since L19 removed] Comment #50 L20. Location Certification: Location provided MUST be certified. This doesn't account for a GPS chip in a PDA or cell phone, therefore this=20 cannot be a MUST. [RM - n/a since L20 removed] Comment #51 L20 Motivation: The Emergency Caller must be able to establish a session with the access domain authenticating and validating entity to obtain a certified location. The authentication of the location is granted with an expiry time, after which the location within the domain is deemed invalid. "INVALID"? This is starting to look an awful lot like a DHCP lease=20 operation, and we're not building a protocol to do this here. [RM - n/a since L20 removed] Comment #52 L21. Location and Emergency Caller Identity: It MUST NOT be assumed that Emergency Caller identity provided with location is true identity of Emergency Caller. This contradicts L18 [RM - n/a since L21 removed] Comment #53 L22. Location Acceptability: Location provided by Emergency Caller MUST be considered acceptable as input to authentication and validation entity. This isn't really clear. Location should be in a certain format, and there=20 is a 'the' missing in the requirement. [RM - n/a since L22 removed] Comment #54 L22. Location Acceptability: Location provided by Emergency Caller MUST be considered acceptable as input to authentication and validation entity. I see no requirement creating an "authentication and validation entity"=20 which this requirement assumes already exists for every user. [RM - n/a since L22 removed] Comment #55 L24. Location Query Authorization: The ability to query emergency caller location using a location key MUST be limited to authorized end points. "end points" (which is one word BTW) Should be replaced with: "requests" [RM - n/a since L24 removed] Comment #56 L24 Motivation: Where the Emergency Caller does not desire the transmission of their location in-band with their call setup, they shall have the option of requesting a unique query key such that only authorized end points may query the location directly from the domain. As stated above: "end points" (which is one word) Should be replaced with: "requests" As "endpoints" implies the actual device has an SA relationship with the database server, which may not be the case, and only the user created an SA=20 from a log-in screen. This is a two level operation. [RM - n/a since L24 removed] Comment #57 L25. Location Domain Authorization: Location Source entity MUST be authorized within the access domain. This is starting to create an architecture now... and I think this is=20 starting to overstep some bounds of the charter and belongs more in NENA than IETF [RM - n/a since L25 removed] Comment #58 L26. Endpoint Location: Location MUST be tied to an endpoint within the access domain at the time of an emergency call. GPSs violate this, so this cannot be a MUST - see L27 below [RM - n/a since L26 removed] L27. Location Sources: Single source of location MUST NOT be assumed. Motivation: To achieve this, the end user device MUST be able to retrieve its current location from the access provider, from the infrastructure, via GPS, ... or as last resort, from the user itself. [RM - n/a since L27 removed] Comment #59 L28. Location Provided: Endpoint location SHOULD be provided to ECC. This needs to be restated as "if location is provided to the routing proxy,=20 it MUST be provided to the ECC. [RM - see rewritten L28] Comment #60 6. Identifying the Appropriate Emergency Call Center From the previous section, we take the requirement of a single (or small number of) emergency addresses which are independent of the caller's location. However, since for reasons of robustness, jurisdiction and local knowledge, PSAPs only serve a limited geographic region, having the call reach the correct PSAP is crucial. While a PSAP may be able to transfer an errant call, any such transfer is likely to add tens of seconds to call setup latency and is prone to errors. (In the United States, there are about 6,100 PSAPs.) I'd like to see the data justifying this last claim of 10s of seconds=20 statement going forward with IP. [RM - take to the list] Comment #61 6. Identifying the Appropriate Emergency Call Center From the previous section, we take the requirement of a single (or small number of) emergency addresses which are independent of the caller's location. However, since for reasons of robustness, jurisdiction and local knowledge, PSAPs only serve a limited geographic region, having the call reach the correct PSAP is crucial. While a PSAP may be able to transfer an errant call, any such transfer is likely to add tens of seconds to call setup latency and is prone to errors. (In the United States, there are about 6,100 PSAPs.) And only about 600 regions, so this might not be so hard with IP and=20 endpoint provided location Comment #62 Section 6, second paragraph at the end: A UA could conceivably store a complete list of all PSAPs across the world, but that would require frequent synchronization with a master database as PSAPs merge or jurisdictional boundaries change. "change"? This likely isn't so often, BTW Comment #63 Section 6, forth paragraph: Note that the first proxy, the ESRP, doing the translation may not be in the same geographic area as the UA placing the emergency call. "...the first proxy, the ESRP..." Does this assume that any proxy that can=20 route based on the location of the caller is an ESRP? Comment #64 I4. Choice of IPSAPs: The emergency caller SHOULD be provided a choice of emergency call centers if more than one exists and is relevant. This gets into defining what an ECC is (which hasn't been done yet), and that if another number is dialed, it doesn't constitute an emergency call IMO. [RM - see rewritten I4] Comment #65 I5. Assuring IPSAP identity: The emergency caller SHOULD be able to determine conclusively that he has reached an accredited emergency call center. How can this possibly be done? If my display says "Dallas Police Dept." ,=20 do I trust it, or do I take the time to verbally question the identity of=20 the calltaker? Do we suggestion questions to be asked to verify the=20 identity of the calltaker? [RM - n/a since I5 removed] Comment #66 I5 Motivation: This requirement is meant to address the threat that a rogue, possibly criminal, entity pretends to accept emergency calls. How can't this be easily faked? [RM - n/a since I5 removed] Comment #67 I6. Warnings for unidentifiable IPSAP. Implementations SHOULD allow callers to proceed, with appropriate warnings or user confirmations, if the identity of the destination IPSAP cannot be verified. How is this verified without there being a root key installed in all UAs? [RM - n/a since I6 removed] Comment #68 I7. Traceable resolution: Particularly for mediated resolution, the caller SHOULD be able to definitively and securely determine who provided the emergency address resolution information. Is this suggesting that all Proxies must remain post transaction/dialog=20 stateful to the user for them to later investigate something? For how long=20 after? [RM - see rewritten I7] Comment #69 I10. Incrementally deployable: An Internet-based emergency call system MUST be able to be deployed incrementally. In the initial stages of deployment, an emergency call may not reach the optimal PSAP. If allowed, emergency calls must only be routed to PSAPs that have agreed to accept non-optimally routed calls. [Ed. Can this be merged with R6?] yes [RM - see rewritten I10] Comment #70 I11. ECC Availability: ECC communication MUST be continuously available. Motivation: From any Internet-connected device it MUST be possible at any time to contact the ECC responsible for the current location with the most appropriate method for communication for the user and the device. is this the famous five 9s? [RM - n/a since I11 removed] Comment #71 I13. Cross-Jurisdiction Device Support: Devices SHOULD support alternate emergency service systems between countries. Motivation: Even as each country is likely to operate their emergency calling infrastructure differently, SIP devices should be able to reach emergency help and, if possible, be located in any country. [Ed. above text needs clarification] yeah, this doesn't make much sense now [RM - original I13 deleted, new proposed text by Brian now included in I-D for discussion] Comment #72 I15: It MUST be possible to route a call based on either a civic or a geo location without requiring conversion from one to the other. This requirement does not prohibit an implementation from converting and using the resulting conversion for routing. how is this different from I14? [RM - n/a since I15 removed] Comment #73 I16: It MUST be possible for a designated 9-1-1 authority to a PSAP to approve of any geocoding database(s) used to assist in determining call routing to that PSAP. Mechanisms must be provided for the PSAP designated 9-1-1 authorities to test and certify a geocoding database as suitable for routing calls to the PSAP. The PSAP may choose to NOT avail itself of such a mechanism. This is implementation - and shouldn't be in here [RM - n/a since I16 removed] Comment #74 I17: It MUST be possible for the designated 9-1-1 authority to supply, maintain, or approve of databases used for civic routing. Mechanisms must be provided for a designated authority for a PSAP to test and certify a civic routing database as suitable for routing calls to that PSAP. This is implementation - and doesn't belong here [RM - n/a since I17 removed] Comment #75 I18: It MUST be possible for the PSAP itself (or a contractor it nominates on its behalf) to provide geocode and reverse geocode data and/or conversion services to be used for routing determination. This implies definition of a standard interchange format for geocode data, and protocols to access it. This has nothing to do with Routing the call, and shouldn't be in here. [RM - n/a since I18 removed] Comment #76 I20: 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. [Ed. Available from where? Please clarify. In the PIDF-LO I think [RM - n/a since I20 removed] Comment #77 I21: It MUST be possible to use various combined components of the location object for determination of routing. 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. No assumption should be made on the granularity of routing boundaries or about the combination of components used. The last sentence alone should be the requirement: "No assumption should be made on the granularity of routing boundaries or about the combination of components used." and the text above this sentence removed or used as explanation only. [RM - n/a since I21 removed] Comment #78 I22: Boundaries mechanisms for geo routing MUST be able to be specific to a natural political boundary, a natural physical boundary (such as a river), or the boundaries listed in the previous requirement. This is repetitive [RM - n/a since I22 removed] Comment #79 I23: Any given geographic location SHOULD result in identification of a unique governmentally-authorized PSAP entity for that location? This is repetitive [RM - n/a since I23 removed] Comment #80 I24: 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. Too US centric [RM - n/a since I24 removed] Comment #81 I25: Carriers, enterprises and other entities that route emergency calls MUST be able to route calls from any location to its appropriate PSAP. "... to its appropriate PSAP should be replaced with "...towards its appropriate ECC." as the first proxy might no have enough knowledge to do it all [RM - see rewritten I25] Comment #82 I26: It MUST be possible for a given PSAP to decide where its calls should be routed. repetitive [RM - n/a since I26 removed] Comment #83 I27: 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. implementation - should be in NENA, not IETF For example, a state may wish to have all emergency calls placed within that state directed to a specific URI. This does NOT imply a single answering point; further routing may occur beyond the common URI. [RM - n/a since I27 removed] Comment #84 I28: Routing MAY change on short notice due to local conditions, traffic, failures, schedule, etc. this is true with anything IP based, what's the requirement? [RM - n/a since I28 removed] Comment #85 I32: Multiple types of failures MAY have different contingency routes. Is this a requirement? [RM - n/a since I32 removed] Comment #86 I33: It MUST be possible to provide more than one contingency route for the same type of failure. Duplicate of I31 [RM - n/a since I33 removed] Comment #87 I34: A procedure MUST be specified to handle "default route" capability when no location is available or the location information is corrupted. I34 and I35 state the same thing currently [RM - n/a since I34 removed] Comment #87 I35: Default routes MUST be available when location information is not available. I34 and I35 state the same thing currently [RM - n/a since I35 removed] Comment #88 I36: Entities routing emergency calls SHALL retain information used to choose a route for subsequent error resolution. "... retain information" for how long? [RM - n/a since I36 removed] Comment #89 I37: Access Infrastructure providers MUST provide a location object that is as accurate as possible when location measurement or lookup mechanisms fail. "... MUST provide a location object". This is stated incorrectly, the AIP=20 doesn't give the UA its PIDF-LO, it gives it an LCI in most cases. The UA=20 builds/generates the PIDF-LO. [RM - n/a since I37 removed] Comment #90 I38: Location available at the time that the call is routed MAY not be accurate. Is this a requirement? It's not written as one [RM - n/a since I38 removed] Comment #91 I39: It SHOULD be possible to have updates of location (which may occur when measuring devices provider early, but imprecise "first fix" location) which can change routing of calls. "... updates of location"... This is a duplicate (L13) [RM - n/a since I39 removed] Comment #92 7. Emergency Address Directory General comment on this whole section - isn't this sufficiently in the=20 background that this is "architecture" and not "identification" or=20 "routing" in that it doesn't belong in the IETF (but more like NENA)? Comment #93 D1. ECC Identification: Public access to ECC selection information MUST be assumed. Need to mention this is "read only" access [RM - see rewritten D1] Comment #94 D2. Assuring directory identity: The query agent (e.g UA or server) MUST be able to assure that it is querying the intended directory. Without a shared key exchange (ensuring the correct destination is=20 contacted), how can this be accomplished? [RM - n/a since D2 removed] Comment #95 D3. Query response integrity: The query agent MUST be able to be confident that the query or response has not been tampered with. Suggested rewrite to: "The query agent MUST take appropriate steps to=20 ensure the query or response maintained integrity." [RM - n/a since D3 removed] Comment #96 D4. Assurance of Update integrity: Any update mechanism for the directory MUST ensure that only authorized users can change directory information and must keep an audit log of all change transactions. This smells like an architectural implementation requirement, therefore it=20 doesn't belong here [RM - n/a since D4 removed] Comment #97 D6. Multiple directories: A UA or proxy SHOULD be able to use multiple (separate) directories to resolve the emergency identifier. If this can ever be manually entered in a UA or a network server to then be=20 distributed to that network's UAs, then this requirement needs to be opened=20 up to "UA or Proxy or other server SHOULD..." [RM - n/a since D6 removed] Comment #98 D7. Referral: All directories SHOULD refer out-of-area queries to an appropriate default or region-specific directory. Not sure how this applies to ECRIT [RM - see rewritten D7] Comment #99 D8. Multiple query protocols: Directories MAY support multiple query protocols. What does this have to do with routing or identification? [RM - n/a since D8 removed] Comment #100 D9. Baseline query protocol: A mandatory-to-implement protocol MUST be specified. Suggested rewording: " A single mandatory-to-implement protocol MUST be=20 specified. Other optional protocols may be listed to give guidance if=20 another protocol is preferred." [RM - D9 to be rewritten, needs an volunteer, why not submit it as above?] Comment #101 C1. Identity: The system SHOULD allow (but not force) the identification of both the caller's identity and his or her terminal network address. Doesn't this violate a previous requirement stating the caller's identity=20 cannot be assumed (L21). Plus the definition of "basic emergency service"=20 states this. [RM - n/a since C1 removed] Comment #102 C2. Privacy override: The end system MUST be able to automatically detect that a call is an emergency call and override any privacy settings that conflict with emergency calling. This doesn't go deep enough into how a jurisdiction may limit how private a=20 caller can remain when calling an ECC. Or the opposite can be true. [RM - n/a since C2 removed] Comment #103 C3. Recontacting Endpoint: The ECC SHOULD have the capability to recontact the initiating endpoint after disconnection. Retitle "Reestablish Communication with Endpoint" [RM - n/a since C3 removed] Comment #104 C3 Motivation: Capability to re-contact the contacting device from the ECC in case of disruption or later query for a tbd period of time. This should also be possible from conventional ECC via temporary (virtual) E.164 numbers. All IP means you cannot assume E.164. [RM - n/a since C3 removed] Comment #105 S1. Authentication override: All outbound proxies and other call filtering elements MUST be able to be configured so that they allow unauthenticated emergency calls. Reword "... MUST be able to be configured..." to "...MUST be configurable..." [RM - n/a since S1 removed] Comment #106 S2. Mid-call features: The end system MUST be able to recognize an emergency call and allow configuration so that certain call features are not triggered accidentally. Reword " The end system MUST be able to recognize an emergency call and=20 allow configuration so that certain call features are not triggered=20 accidentally." To " The end system MUST recognize it initiated an emergency=20 call and prevent certain call features that interfere with that call (e.g.=20 call waiting, call hold)." [RM - n/a since S2 removed] Comment #107 In Just after S2 - there needs to be a requirement added stating something=20 to the affect that "...once a UA initiates an emergency call, system=20 resources SHOULD be prevented from certain call features that interfere=20 with that call (e.g. Barge, call preemption). The latter example is for=20 military or government networks. Comment #108 S3. Testable: A user SHOULD be able to test whether a particular address reaches the appropriate PSAP, without actually causing emergency help to be dispatched or consuming PSAP call taker resources. How can't this be faked? [RM - n/a since S3 removed] Comment #109 S6 Tracking and Tracing Facilities for all calls MUST be provided. This includes all routing entities as well as all signaling entities. "Facilities" reads like circuits and lines. What is meant here? [RM - n/a since S6 removed] Comment #110 S7 Each element in the signaling and routing paths solution SHALL maintain call detail records that can be accessed by management systems to develop call statistics in real time. Does it really need to be in real-time? Are we talking RTCP statistics? Is=20 this something CALEA would want? How far towards the UAC can a ECC Net Mgmt=20 station gain access to SIP element CDR information? How doesn't this look=20 like a means of attack into an enterprise? [RM - n/a since S7 removed] Comment #111 S8 Each element of the signaling and routing paths SHALL provide congestion controls. We're talking RSVP and/or MPLS now? Diffserv doesn't do this, and the ECN=20 proposal from Nortel is getting some pushback from Sally Floyd and Fred Baker. [RM - n/a since S8 removed] Comment #112 S9 It SHALL be possible to determine the complete call chain of a call, including the identity of each signaling element in the path, and the reason it received the call (Call History). We're talking RSVP and/or MPLS now? Diffserv doesn't do this, and the ECN=20 proposal from Nortel is getting some pushback from Sally Floyd and Fred Baker. [RM - n/a since S9 removed] Comment #113 10. Supplemental Information Owner of the structure or tenant? Where is this in our Charter? SOMETHING TO ADD TO THIS DOCUMENT It is the case in Sweden that when a person calls for emergency help, they=20 MUST provide two different locations in the call set-up. #1 - they MUST provide the location they are calling from (in civic or=20 coordinate format); #2 - they MUST provide their billing location (where they personally=20 receive their bills from. The next version of draft-ietf-sipping-location-requirements-02 (in the SIP=20 WG) will account for this. But I on't know if should only be mentioned there. [RM - suggest bringing up on the list] cheers, James ******************* Truth is not to be argued... it is to be presented. Alas, few *truths* exist without the math. ...all else is a matter of perspective _______________________________________________ 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 Jul 01 21:33:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoWsl-0007Ir-Hk; Fri, 01 Jul 2005 21:33:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoWsj-0007IS-HL for ecrit@megatron.ietf.org; Fri, 01 Jul 2005 21:33: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 VAA19642 for ; Fri, 1 Jul 2005 21:33:17 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoXIo-0003dO-9m for ecrit@ietf.org; Fri, 01 Jul 2005 22:00:18 -0400 Received: from [192.168.0.31] (pool-141-153-166-25.mad.east.verizon.net [141.153.166.25]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j621XHsV013558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Jul 2005 21:33:18 -0400 (EDT) Message-ID: <42C5EEDA.4020601@cs.columbia.edu> Date: Fri, 01 Jul 2005 21:33:14 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] R5 References: <8C837214C95C864C9F34F3635C2A65750297F463@SEA-EXCHVS-2.telecomsys.com> <42C44CB8.5070106@cs.columbia.edu> <42C4520E.8010707@cs.columbia.edu> <42C45858.5000301@cs.columbia.edu> <42C46523.6070603@cs.columbia.edu> <42C46D20.5080301@cs.columbia.edu> <42C4B3EE.3020400@cs.columbia.edu> <68737CB5-BF0E-47F4-8F96-7F87DD878300@hxr.us> <42C57EB3.3050600@cs.columbia.edu> <0FF0418D-EDFF-4F14-A1A4-8CD1E0B05274@hxr.us> <42C599DE.3000400@cs.columbia.edu> 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: 25620135586de10c627e3628c432b04a 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 Andrew Newton wrote: > > On Jul 1, 2005, at 3:30 PM, Henning Schulzrinne wrote: > >> This has nothing to do with single points of failure. > > > The box you are insisting on putting between the client and the mapping > service is a single point of failure. I'm sorry, but I'm not sure which box you're talking about. If you mean the box run by the ISP or VSP, it clearly can't be a single box, just like no sane ISP will put a single local DNS server in its network. I would consider this pretty obvious, but maybe this isn't. > First, zone transfers in DNS are not related to answering normal DNS > queries such as converting a domain name to an IP address. In fact, > most DNS administrators either turn it off or severely restrict to whom > it will answer. None of the name servers my company run get their data > via zone transfer, yet we answer a lot of DNS queries every second. I think it would help the discussion if you didn't put words in my mouth. I never said that zone transfers are used to answer normal queries. > > Second, the caching you describe does not sound like DNS caching. DNS > caches usually do not contain ALL the data from ALL the authoritative > servers they talk to. And they generally don't query the authoritative > servers upon a cache hit just to see if the data has changed. The detailed cache algorithm is a trade-off. The principle is the same. It's an orthogonal issue as to whether they should query the authoritative server or not for each query; in DNS, the TTL allows you to set this and there seem to be quite a few that set that value close to zero (e.g., Akamai-style resolvers). > > What you have been describing is not a cache like what we have with > DNS. You are describing some form of database replication. How that > database replication works does not need to be mixed in with the > protocol used by the client to do a location-to-uri mapping query. > Those are two different functions. Zone transfer is a form of "database replication". Clearly, implementations can support a multitude of mechanisms, but having a standardized one has made DNS significantly more robust and allows mixed-software, loosely-coupled deployments (which is a good thing to avoid catastrophic failure). We (Columbia) can run a secondary at UMich, without worrying about whether UMich runs bind or some other DNS server. > > You stated earlier in this thread that "caching" is one of many ways to > meet your suggested requirement. If there are multiple ways, does the > client query interface have to support them all? I doubt it. I suppose it's incumbent upon those designing hypothetical protocols without such support to show that they can survive the same failure scenarios with equal probability, without relying on "and then there's magic". > > You can still do your database replication without putting that in the > query interface. That is why this is out of scope. I strongly disagree with that conclusion. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 01 21:53:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoXBu-0002sz-AF; Fri, 01 Jul 2005 21:53:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoXBs-0002sr-6l for ecrit@megatron.ietf.org; Fri, 01 Jul 2005 21:53: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 VAA21283 for ; Fri, 1 Jul 2005 21:53:03 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoXbw-0004on-0s for ecrit@ietf.org; Fri, 01 Jul 2005 22:20:05 -0400 Received: from [192.168.0.31] (pool-141-153-166-25.mad.east.verizon.net [141.153.166.25]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j621r4XX004183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Jul 2005 21:53:05 -0400 (EDT) Message-ID: <42C5F37D.4000304@cs.columbia.edu> Date: Fri, 01 Jul 2005 21:53:01 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Hardie Subject: Re: [Ecrit] simplified R5? 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: 73734d43604d52d23b3eba644a169745 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 Ted Hardie wrote: > I'm beginning to strongly suspect that part of R5 belongs in the implementation > and deployment docs, rather than as a protocol requirement. Going through > Henning's scenario (in which the fresh data is first checked, but the > local copy is available), I realized that we could run that exact scenario > in reverse--the local copy is not available, but the "parent" copy is > available by some onerous network path. Checking the local copy first > might be sensible in some network topologies, and preferring one over > the other seems problematic. My "algorithm" was just a short-hand, albeit ill-formulated, for a standard DNS-like caching algorithm, with the immediate query representing a TTL of 0. The only real difference to DNS or web caching is that these don't typically deal with the fact of connectivity loss and cache expiration, as far as I know. A system suitable for emergencies has to consider that issue. > > > That led me to a far simpler protocol requirement--the the protocol must > be able to support topologically distinct redundant servers. Whether these > get updated via pull-based caching, a replication process, or the seasonal > migration of avian carriers doesn't really enter into what the client needs to do--- > check a second identified server if the first one craps out. For the current > work of ECRIT, this seems in scope, where some elements of the other > discussion look out of scope. Topologically distinct is clearly necessary, but not good enough. Unlike in a normal network scenario, where large-scale failures are rare, for emergency calling, you can easily imagine that only relatively local connectivity remains. Having servers in CA and MA doesn't help much if the local cable company in NY is still up (and connected to the local PSAP), but has lost upstream connectivity to the rest of the Internet (or that connectivity is severely overloaded). I want to be able to deploy reliable systems that are standards-based, not just rely on some background magic to somehow make this happen. > > Also, I really fear that R5 as discussed (though possibly not as written) > implies that the infrastructure for mapping be maintained by the access > provider, even though the voice services provider 1) is responsible for > delivering the call, 2) must be up and available to do so, and 3) has > a business reason to do so (the other is an "unfunded mandate" that > regulation might achieve but the market will resist). That may be > a common thing, but I believe we have to support scenarios where > it isn't the way the deployment works. As I noted earlier, based on your note, the network path includes both the call signaling and the media path. Thus, the MSP could just as easily host this server, without endangering fate sharing (assuming that it requires an outbound proxy). In addition, the VSP does *not* have to be "up and available" to serve the call. At least in a SIP environment, if the end system or an "emergency" proxy in the local network does ECRIT lookup, the end system can directly connect to the PSAP, without the MSP being involved at all. Given that it is common mandate that cell phones can place 911 calls without being active subscribers to a service, this may occur with some frequency. > > As a proposal, I'd like to suggest we scrap R5 as written, replace it with > "the protocol must support topologically distinct redundant servers", and > discuss the good ways of achieving that in the deployment doc. For the reasons noted, I think that shortchanges an important design consideration. > > regards, > Ted Hardie > > _______________________________________________ > 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 Sun Jul 03 10:15:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp5Bn-0006Tf-Jj; Sun, 03 Jul 2005 10:11:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp5Bl-0006TW-4b for ecrit@megatron.ietf.org; Sun, 03 Jul 2005 10:11: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 KAA00572 for ; Sun, 3 Jul 2005 10:11:15 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dp5c8-0001Qy-Mh for ecrit@ietf.org; Sun, 03 Jul 2005 10:38: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] Fwd: I-D ACTION:draft-hardie-ecrit-iris-01.txt Date: Sun, 3 Jul 2005 16:14:28 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BFE0@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] Fwd: I-D ACTION:draft-hardie-ecrit-iris-01.txt Thread-Index: AcV9dUdZVRSfF/KcQ4yKYV5bSIZ2twCXoRwn From: "Stastny Richard" To: "Andrew Newton" , X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 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 nice draft ;-) =20 Thanks for incorporating many potential emergency services=20 (sos identifiers), but I fear that this list will be open ended. So why not add a service discovery query type as I already proposed to Hennings draft "FindEconServiceTypes" to discover the service types available at a given location. =20 next:issue: I am not able to completely understand the following paragraph in section 3.3.1 "The primary information relayed in this result are URIs to be used = to make contact with emergency services. This result may contain multiple URIs. These URIs are not provided in preference order, and clients MUST NOT attach preference to any URI based upon its position in the list. Server MUST NOT provide more than one URI of the scheme in a result (e.g. two "sip:" URIs are not allowed). The purpose of providing multiple URIs is to offer multiple methods of contact." =20 Is it now one or more URIs? IMHO what you may mean here is that for one service type not more than one URI may be given, but more then one service types may be replied for a query. See also the dicussion with Henning on LUMP, where one queries for "ecc" and gets back a list of "fire", "police", etc. =20 In any case, what is missing in the resulttype "emergencyContactType" is the "serviceType" which is more important then the "Displayname" =20 Talking about a hierarchy of emergency services as prposed by Henning in LUMP e.g. emergency,police and your proposal with a flat structure e.g. "ecc," "fire", "rescue" and also looking at the example you give by querying in the U.S. for "police" and getting back the "NYPD" =20 I have a serious problem here: =20 Either the example is not well choosen or there is a potential (legal or scope) problem lurking here. =20 We are talking withn ECRIT about "emergency services" What an "emergency service" or an "emergency number" is, is very well defined in national laws and/or ordinances. =20 I always thought (please correct me if I am wrong) that in=20 the U.S. there is only ONE emergency number, namely "911", e.g. in the U.K there is "999" =20 So basically if I query for "police" or any other service type in the US, I have to get back an "ecc" service type=20 and not the "NYPD". =20 Now in some European countries (a.g in Austria) the situation IS different. Service type "ecc"=3D112 AND e.g. "police"=3D133 CO-EXIST in parallel (by law), which is BTW also a problem with Hennings hierachical approach, because there exists in addition to emergency and emergency.police also an emergency.emergency (or emergency.ecc) =20 If you wanted to describe in your a example the possibility to call the police in ADDITION with a NON-EMERGENCY call, this may be useful, because also in Austria there exists the possibility to call the e.g. local police station direct, if you have a non-emergency request. It could be useful to provide also a mapping for this, but IMHO then the whole issue has a potential to get out of hand. =20 In any case, an additional indicator if the URI provided is an emergency URI or not is required. =20 regards Richard ________________________________ Von: ecrit-bounces@ietf.org im Auftrag von Andrew Newton Gesendet: Do 30.06.2005 15:06 An: 'ecrit@ietf.org' Betreff: [Ecrit] Fwd: I-D ACTION:draft-hardie-ecrit-iris-01.txt=20 Hannes, Ted, and I have put together another version of our ecrit- iris draft. This is an XML-based interface capable of using UDP for=20 fast exchanges and DNS SRV records for load-balancing and robustness. We made the following changes: o Added a validation flag so that the query interface may be used=20 for address validation. o Updated the list of sos identifiers based on Richard's email. o Beefed up the introductory section for readability (though more=20 of that will have to be done). -andy Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: June 28, 2005 3:50:02 PM EDT > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-hardie-ecrit-iris-01.txt > Reply-To: internet-drafts@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > > > Title : An IRIS schema for Emergency Service contact URIs > Author(s) : T. Hardie, et al. > Filename : draft-hardie-ecrit-iris-01.txt > Pages : 25 > Date : 2005-6-28 > > This document describes an XML-based protocol for passing location > information to a server that returns emergency service contact=20 > URIs. > It is intended to fit within a larger framework of standards. > Specifically, it presumes the existence of a URI scheme appropriate > for signalling that emergency service is required and=20 > distinguishing > among emergency services if appropriate. It also presumes that an > entity requesting this response will be able to handle the URIs > returned as input to appropriate handlers. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-hardie-ecrit-iris-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=20 > 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=20 > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-hardie-ecrit-iris-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-hardie-ecrit-iris-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=20 > 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. > Content-Type: text/plain > Content-ID: <2005-6-28150349.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > _______________________________________________ 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 Jul 05 09:42:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpngj-0001yu-NK; Tue, 05 Jul 2005 09:42:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpngi-0001yX-M8 for ecrit@megatron.ietf.org; Tue, 05 Jul 2005 09:42: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 JAA20053 for ; Tue, 5 Jul 2005 09:42:06 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dpo5i-00085Z-AP for ecrit@ietf.org; Tue, 05 Jul 2005 10:08:02 -0400 Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Tue, 05 Jul 2005 09:40:09 -0400 id 001502F3.42CA8DB9.00002707 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613BFE0@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D4613BFE0@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9CF11CCD-76ED-455B-89A8-E8942E907CCF@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Fwd: I-D ACTION:draft-hardie-ecrit-iris-01.txt Date: Tue, 5 Jul 2005 09:40:06 -0400 To: Stastny Richard X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a 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 Richard, Thanks for reading the draft. Based on your feedback, I can already see changes we need to make. Many of the concerns you raise are not specific to ECON or LUMP, but are general issues that need to be resolved by this working group. My comments are in-line: On Jul 3, 2005, at 10:14 AM, Stastny Richard wrote: > > nice draft ;-) Thanks. > Thanks for incorporating many potential emergency services > (sos identifiers), but I fear that this list will be open ended. We added the new identifiers because they did not seem to have immediate overlap with the existing ones. That doesn't mean it is the final list. We should strive for a comprehensive and unambiguous list that is as universal as possible for the purposes of internationalization (or more specifically, having those identifiers localized by the client). > So why not add a service discovery query type as I > already proposed to Hennings draft > "FindEconServiceTypes" to discover the service types > available at a given location. As I see it, the problem with this type of query is that it adds latency and can lead to internationalization problems. Is this use case for such a query? 1 User -> Service :: Find location map for service XXX. 2 Service -> User :: Service XXX is unknown. 3 User -> Service :: What are the service types supported? 4 Service -> User :: Here is the list? 5 User -> Service :: Find location map for service YYY. That is a lot of round trips and there is still the potential that the user won't understand a thing on the list (if it isn't in their language). > next:issue: I am not able to completely understand > the following paragraph in section 3.3.1 > "The primary information relayed in this result are URIs to be > used to > make contact with emergency services. This result may contain > multiple URIs. These URIs are not provided in preference order, > and > clients MUST NOT attach preference to any URI based upon its > position > in the list. Server MUST NOT provide more than one URI of the > scheme > in a result (e.g. two "sip:" URIs are not allowed). The purpose of > providing multiple URIs is to offer multiple methods of contact." > > Is it now one or more URIs? This relates to URI scheme types, such as sip: vs. xmpp: etc... > IMHO what you may mean here is that for one service type not > more than one URI may be given, but more then one service > types may be replied for a query. See also the dicussion with > Henning on LUMP, where one queries for "ecc" and gets back > a list of "fire", "police", etc. This sounds like a reasonable restriction. > In any case, what is missing in the resulttype > "emergencyContactType" is the "serviceType" > which is more important then the "Displayname" That is an excellent suggestion. The purpose of the display name is for user feedback. Even if they don't really understand it, when the UI updates with the display name it gives feedback and suggestion that a phase of the emergency signaling/calling process has completed. > Talking about a hierarchy of emergency services as prposed > by Henning in LUMP e.g. emergency,police and your > proposal with a flat structure e.g. "ecc," "fire", "rescue" > and also looking at the example you give by querying > in the U.S. for "police" and getting back the "NYPD" I don't think we (the co-authors of the draft) have any rigid opinion about this being flat or hierarchical. If a hierarchical structure works, then that is fine. We are concerned with adding latency, too much complexity (not to imply that you get this with hierarchy), and user experience (e.g. internationalization). > I have a serious problem here: > > Either the example is not well choosen or there is a potential > (legal or scope) problem lurking here. > > We are talking withn ECRIT about "emergency services" > What an "emergency service" or an "emergency number" is, > is very well defined in national laws and/or ordinances. > > I always thought (please correct me if I am wrong) that in > the U.S. there is only ONE emergency number, namely > "911", e.g. in the U.K there is "999" > > So basically if I query for "police" or any other service type > in the US, I have to get back an "ecc" service type > and not the "NYPD". > > Now in some European countries (a.g in Austria) the > situation IS different. Service type "ecc"=112 AND > e.g. "police"=133 CO-EXIST in parallel (by law), which is BTW > also a problem with Hennings hierachical approach, because > there exists in addition to emergency and emergency.police > also an emergency.emergency (or emergency.ecc) In a hierarchical approach, would wild card semantics help? Such as: emergency.* meaning "I have an emergency and want anybody to respond" emergency.police meaning "I have an emergency and need the police" > If you wanted to describe in your a example the > possibility to call the police in ADDITION with > a NON-EMERGENCY call, this may be useful, > because also in Austria there exists the possibility > to call the e.g. local police station direct, if you have > a non-emergency request. It could be useful > to provide also a mapping for this, but IMHO then > the whole issue has a potential to get out of hand. With regard to getting out-of-hand, I tend to agree. And do we really want to provide a use case for people with non-emergencies using a resource needed for emergencies? > In any case, an additional indicator if the > URI provided is an emergency URI or not > is required. In the case above where you have outlined that non-emergency URIs can be returned, I would agree. But if the service is specifically limited to emergencies, then wouldn't it be reasonable to assume that all URIs are for emergencies? Thanks for reading the draft. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 05 10:00:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpnyq-00055U-AF; Tue, 05 Jul 2005 10:00:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpnyp-000551-0F for ecrit@megatron.ietf.org; Tue, 05 Jul 2005 10:00: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 KAA24694 for ; Tue, 5 Jul 2005 10:00:51 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpoIl-0001NL-8E for ecrit@ietf.org; Tue, 05 Jul 2005 10:21:33 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 05 Jul 2005 09:53:32 -0400 X-IronPort-AV: i="3.93,261,1115006400"; d="scan'208"; a="61034100:sNHT916979398" 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 j65DrSa0014749; Tue, 5 Jul 2005 09:53:31 -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); Tue, 5 Jul 2005 09:53:30 -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] Fwd: I-D ACTION:draft-hardie-ecrit-iris-01.txt Date: Tue, 5 Jul 2005 09:53:29 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E34EC32D@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] Fwd: I-D ACTION:draft-hardie-ecrit-iris-01.txt Thread-Index: AcV9dUdZVRSfF/KcQ4yKYV5bSIZ2twCXoRwnAGUvQ3A= From: "Michael Hammer \(mhammer\)" To: "Stastny Richard" , "Andrew Newton" , X-OriginalArrivalTime: 05 Jul 2005 13:53:30.0141 (UTC) FILETIME=[ECEC2CD0:01C58168] X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee 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 Richard, Did not understand your comment reference 911 emergency access number and NYPD response contact. Yes, 911 is the designated emergency number, but depending on location the call gets routed to different PSAPs. I don't know the specifics of NY City or what the example is trying to show. But, it is certainly plausible that a call to 911 could get routed to the NYPD if they were operating the PSAP. So, I would expect a query to a database might return a specific address. Mike > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Stastny Richard > Sent: Sunday, July 03, 2005 10:14 AM > To: Andrew Newton; ecrit@ietf.org > Subject: Re: [Ecrit] Fwd: I-D ACTION:draft-hardie-ecrit-iris-01.txt=20 >=20 > Hi all, > =20 > nice draft ;-) > =20 > Thanks for incorporating many potential emergency services=20 > (sos identifiers), but I fear that this list will be open ended. > So why not add a service discovery query type as I already=20 > proposed to Hennings draft "FindEconServiceTypes" to discover=20 > the service types available at a given location. > =20 > next:issue: I am not able to completely understand the=20 > following paragraph in section 3.3.1 > "The primary information relayed in this result are URIs=20 > to be used to > make contact with emergency services. This result may contain > multiple URIs. These URIs are not provided in preference=20 > order, and > clients MUST NOT attach preference to any URI based upon=20 > its position > in the list. Server MUST NOT provide more than one URI of=20 > the scheme > in a result (e.g. two "sip:" URIs are not allowed). The purpose of > providing multiple URIs is to offer multiple methods of contact." > =20 > Is it now one or more URIs? > IMHO what you may mean here is that for one service type not=20 > more than one URI may be given, but more then one service=20 > types may be replied for a query. See also the dicussion with=20 > Henning on LUMP, where one queries for "ecc" and gets back a=20 > list of "fire", "police", etc. > =20 > In any case, what is missing in the resulttype=20 > "emergencyContactType" is the "serviceType" > which is more important then the "Displayname" > =20 > Talking about a hierarchy of emergency services as prposed by=20 > Henning in LUMP e.g. emergency,police and your proposal with=20 > a flat structure e.g. "ecc," "fire", "rescue" > and also looking at the example you give by querying in the=20 > U.S. for "police" and getting back the "NYPD" > =20 > I have a serious problem here: > =20 > Either the example is not well choosen or there is a=20 > potential (legal or scope) problem lurking here. > =20 > We are talking withn ECRIT about "emergency services" > What an "emergency service" or an "emergency number" is, is=20 > very well defined in national laws and/or ordinances. > =20 > I always thought (please correct me if I am wrong) that in=20 > the U.S. there is only ONE emergency number, namely "911",=20 > e.g. in the U.K there is "999" > =20 > So basically if I query for "police" or any other service=20 > type in the US, I have to get back an "ecc" service type and=20 > not the "NYPD". > =20 > Now in some European countries (a.g in Austria) the situation=20 > IS different. Service type "ecc"=3D112 AND e.g. "police"=3D133=20 > CO-EXIST in parallel (by law), which is BTW also a problem=20 > with Hennings hierachical approach, because there exists in=20 > addition to emergency and emergency.police also an=20 > emergency.emergency (or emergency.ecc) > =20 > If you wanted to describe in your a example the possibility=20 > to call the police in ADDITION with a NON-EMERGENCY call,=20 > this may be useful, because also in Austria there exists the=20 > possibility to call the e.g. local police station direct, if=20 > you have a non-emergency request. It could be useful to=20 > provide also a mapping for this, but IMHO then the whole=20 > issue has a potential to get out of hand. > =20 > In any case, an additional indicator if the URI provided is=20 > an emergency URI or not is required. > =20 > regards > Richard >=20 > ________________________________ >=20 > Von: ecrit-bounces@ietf.org im Auftrag von Andrew Newton > Gesendet: Do 30.06.2005 15:06 > An: 'ecrit@ietf.org' > Betreff: [Ecrit] Fwd: I-D ACTION:draft-hardie-ecrit-iris-01.txt=20 >=20 >=20 >=20 > Hannes, Ted, and I have put together another version of our=20 > ecrit- iris draft. This is an XML-based interface capable of=20 > using UDP for fast exchanges and DNS SRV records for=20 > load-balancing and robustness. >=20 > We made the following changes: > o Added a validation flag so that the query interface may=20 > be used for address validation. > o Updated the list of sos identifiers based on Richard's email. > o Beefed up the introductory section for readability=20 > (though more of that will have to be done). >=20 > -andy >=20 > Begin forwarded message: >=20 > > From: Internet-Drafts@ietf.org > > Date: June 28, 2005 3:50:02 PM EDT > > To: i-d-announce@ietf.org > > Subject: I-D ACTION:draft-hardie-ecrit-iris-01.txt > > Reply-To: internet-drafts@ietf.org > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > > > > > > Title : An IRIS schema for Emergency Service contact URIs > > Author(s) : T. Hardie, et al. > > Filename : draft-hardie-ecrit-iris-01.txt > > Pages : 25 > > Date : 2005-6-28 > > > > This document describes an XML-based protocol for passing location > > information to a server that returns emergency service contact=20 > > URIs. > > It is intended to fit within a larger framework of standards. > > Specifically, it presumes the existence of a URI scheme=20 > appropriate > > for signalling that emergency service is required and=20 > > distinguishing > > among emergency services if appropriate. It also=20 > presumes that an > > entity requesting this response will be able to handle the URIs > > returned as input to appropriate handlers. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-hardie-ecrit-iris-01.txt > > > > To remove yourself from the I-D Announcement list, send a=20 > message to=20 > > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of=20 > > the message. > > You can also visit=20 > 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=20 > > username "anonymous" and a password of your e-mail address. After=20 > > logging in, type "cd internet-drafts" and then > > "get draft-hardie-ecrit-iris-01.txt". > > > > A list of Internet-Drafts directories can be found in=20 > > http://www.ietf.org/shadow.html or=20 > > 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-hardie-ecrit-iris-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=20 > > 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=20 > > implementation to automatically retrieve the ASCII version of the=20 > > Internet-Draft. > > Content-Type: text/plain > > Content-ID: <2005-6-28150349.I-D@ietf.org> > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/i-d-announce > > >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=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 Tue Jul 05 18:07:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpva8-0001JV-Bi; Tue, 05 Jul 2005 18:07:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpva6-0001It-QC for ecrit@megatron.ietf.org; Tue, 05 Jul 2005 18:07: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 SAA06277 for ; Tue, 5 Jul 2005 18:07:49 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpvuQ-00060J-8t for ecrit@ietf.org; Tue, 05 Jul 2005 18:28:54 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j65M0edd026258; Tue, 5 Jul 2005 15:00:40 -0700 (PDT) Received: from [192.168.1.4] (vpn-10-50-0-32.qualcomm.com [10.50.0.32]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j65M0aTT010685; Tue, 5 Jul 2005 15:00:37 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <42C5F37D.4000304@cs.columbia.edu> References: <42C5F37D.4000304@cs.columbia.edu> Date: Tue, 5 Jul 2005 15:00:34 -0700 To: Henning Schulzrinne From: Ted Hardie Subject: Re: [Ecrit] simplified R5? Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 At 9:53 PM -0400 7/1/05, Henning Schulzrinne wrote: >> >>That led me to a far simpler protocol requirement--the the protocol must be able to support topologically distinct redundant servers. Whether these get updated via pull-based caching, a replication process, or the seasonal migration of avian carriers doesn't really enter into what the client needs to do--- >>check a second identified server if the first one craps out. For the current >>work of ECRIT, this seems in scope, where some elements of the other >>discussion look out of scope. > >Topologically distinct is clearly necessary, but not good enough. Unlike in a normal network scenario, where large-scale failures are rare, for emergency calling, you can easily imagine that only relatively local connectivity remains. The point I was making is that topologically distinct allows you to deal with both local failures and large-scale failure. To flesh this out: you have power and network connectivity to a DC-powered DSLAM where the power surge in the CO after your emergency fried all the AC-powered servers. Having the topologically distinct master server available means you can still get the mapping done to call for help. From the client's perspective, what it needs is a list (probably an ordered list) of servers it can use. From a deployment perspective, what we need is sensible distribution of the servers--and that can include many different kinds of replication, including "local cache of master server", but this is deployment advice, not a protocol requirement. > >As I noted earlier, based on your note, the network path includes both the call signaling and the media path. Thus, the MSP could just as easily host this server, without endangering fate sharing (assuming that it requires an outbound proxy). Sorry, assuming what require an outbound proxy? I think I lost your point here. >In addition, the VSP does *not* have to be "up and available" to serve the call. At least in a SIP environment, if the end system or an "emergency" proxy in the local network does ECRIT lookup, the end system can directly connect to the PSAP, without the MSP being involved at all. Given that it is common mandate that cell phones can place 911 calls without being active subscribers to a service, this may occur with some frequency. I think you misunderstood me. I'm saying if we *require* the access provider to handle the infrastructure, it is an unfunded mandate; we can certainly design so that they *may* provide it, but we also out to take into account deployments where they do not and someone like the VSP does. But I don't think we can handle requirements where the access provider isn't available--if they're not up, the bits don't flow. Again, I think the protocol requirement here is to be able to handle multiple, topologically distinct servers. Describing where it is sensible to keep these multiple copies is useful stuff, but it is not a protocol requirement. regards, Ted Hardie _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 06 06:45:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq7PW-0006FN-UZ; Wed, 06 Jul 2005 06: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 1Dq7Ma-0003Tq-PH for ecrit@megatron.ietf.org; Wed, 06 Jul 2005 06:42: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 GAA22772 for ; Wed, 6 Jul 2005 06:41:29 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dq7XN-0001J0-1F for ecrit@ietf.org; Wed, 06 Jul 2005 06:53:53 -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] Fwd: I-D ACTION:draft-hardie-ecrit-iris-01.txt Date: Wed, 6 Jul 2005 12:24:25 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B206B@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] Fwd: I-D ACTION:draft-hardie-ecrit-iris-01.txt Thread-Index: AcWBZ44GH3CPnyr+Q9Ol5yEnT6GwngAo6d8Q From: "Stastny Richard" To: "Andrew Newton" X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b 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 Andy, Thanks for your reply > Many of the concerns you raise are not > specific to ECON or LUMP, but are general issues that need to be > resolved by this working group Yes, many of the issues I raised in my reply to LUMP also applies to ECON. I have also similar questions related to administration, but since I am not so familiar with IRIS (yet), I first need to get some more basic information. > That doesn't mean it is the final list. =20 The question is if there will ever be a final list ;-) > We should strive for a comprehensive and unambiguous > list that is as universal as possible for the purposes of > internationalization (or more specifically, having those identifiers > localized by the client). > That is a lot of round trips and there is still the potential that > the user won't understand a thing on the list (if it isn't in their > language). I agree that as much services as possible should be=20 Internationalized and predefined, to allow native translations. On the other side additional national services should be possible, they may have only local meaning anyway. I do not think that the round trips are a problem, because service discovery should take place at connect time and not at the time you make an emergency call. Do not forget that there may also be a emergency service reachability indicator. This would also happen at connect time. >In a hierarchical approach, would wild card semantics help? Yes, I think so, as proposed in LUMP, although this may still need some discussion. Citizens from countries used to only one emergency number may not be aware of the options. On the other hand, they may get confused. I have no idea if already in all countries having different emergency numbers also 112 or 911 like access is available in addition Any comments? > With regard to getting out-of-hand, I tend to agree. And do we > really want to provide a use case for people with non-emergencies > using a resource needed for emergencies? I agree, but there is a problem lurking regarding dialing plans, but this is out of scope in ECRIT. But I basically have no idea where this problem is to be discussed: (IPTEL, ENUM ?) End-users on VoIP either use the home dialing plan or the international E.164 numbering plan (i.e. +44 xxx xxx) Short codes used for emergency and also non-emergency numbers are non-E.164 numbers, so they cannot be dialled in E.164 format and can also not be dialled from a dialing plan of another country, so they can basically NOT be dialled at all by users roaming in another country. Mobile operators have special agreements to provide roaming users access to these numbers. So we have three issues here: 1. Access to emergency numbers (ECRIT) 2. Access to police, etc in non-emergency cases (ECRIT?) 3. Access to other non-e.164 numbers (short codes) (IPTEL?, ENUM?) Richard Richard Stastny OeFEG tel:+43 664 420 4100 enum:+43 780 203 211 callto://fordprefect http://voipandenum.blogspot.com =20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 06 06:58:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq7br-0000tZ-Fx; Wed, 06 Jul 2005 06:58:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq7bq-0000tR-FH for ecrit@megatron.ietf.org; Wed, 06 Jul 2005 06:58: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 GAA27672 for ; Wed, 6 Jul 2005 06:58:25 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dq7sR-0005o7-RQ for ecrit@ietf.org; Wed, 06 Jul 2005 07:15:41 -0400 Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Wed, 06 Jul 2005 06:47:42 -0400 id 0010F799.42CBB6CF.000059E2 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B206B@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D461B206B@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Fwd: I-D ACTION:draft-hardie-ecrit-iris-01.txt Date: Wed, 6 Jul 2005 06:47:40 -0400 To: "Stastny Richard" X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 Richard, I have a few followup comments and questions. On Jul 6, 2005, at 6:24 AM, Stastny Richard wrote: > I agree that as much services as possible should be > Internationalized and predefined, to allow native translations. > On the other side additional national services should be > possible, they may have only local meaning anyway. I agree. > I do not think that the round trips are a problem, because > service discovery should take place at connect time and > not at the time you make an emergency call. Do not > forget that there may also be a emergency service > reachability indicator. This would also happen at > connect time. What do you mean by "connect time"? Is this when a device acquires an IP address on a network? And what is the reachability indicator? > So we have three issues here: > > 1. Access to emergency numbers (ECRIT) > 2. Access to police, etc in non-emergency cases (ECRIT?) > 3. Access to other non-e.164 numbers (short codes) (IPTEL?, ENUM?) This sounds like a discussion topic for Paris. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 06 07:15:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq7s8-0004u6-JG; Wed, 06 Jul 2005 07:15:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq7s3-0004qn-7V for ecrit@megatron.ietf.org; Wed, 06 Jul 2005 07:15: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 HAB00448 for ; Wed, 6 Jul 2005 07:15:09 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dq8Dw-0002ob-Rl for ecrit@ietf.org; Wed, 06 Jul 2005 07:37:54 -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] Fwd: I-D ACTION:draft-hardie-ecrit-iris-01.txt Date: Wed, 6 Jul 2005 13:08:33 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B206C@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] Fwd: I-D ACTION:draft-hardie-ecrit-iris-01.txt Thread-Index: AcWCGKD+WBhtpSd3RZ+PZ6Ejz9VOWgAAQWCw From: "Stastny Richard" To: "Andrew Newton" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 wrote: > > I do not think that the round trips are a problem, because > > service discovery should take place at connect time and > > not at the time you make an emergency call. Do not > > forget that there may also be a emergency service > > reachability indicator. This would also happen at > > connect time. >=20 > What do you mean by "connect time"? Is this when a device acquires > an IP address on a network? > And what is the reachability indicator? Yes Sorry for being unprecise here: The basic idea is that when the device acquires the IP address (and also get eventually its location) to contact the mapping database to retrieve the services available and also tries to contact (silently) the PSAP or ESRP to provide the end-user or device with an indication that the emergency service is reachable This is one of the original requirements (I forgot which number) This also needs to be discussed in Paris also, because this has to be repeated every time the device updates its=20 location (or after a certain time-out) >=20 > > So we have three issues here: > > > > 1. Access to emergency numbers (ECRIT) > > 2. Access to police, etc in non-emergency cases (ECRIT?) > > 3. Access to other non-e.164 numbers (short codes) (IPTEL?, ENUM?) >=20 > This sounds like a discussion topic for Paris. Agreed, the problem here is that IPTEL wnts to close down Maybe a potential new WG on VoIP peering. -Richard >=20 > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 07 13:21:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqa4S-0000Jc-Sm; Thu, 07 Jul 2005 13:21:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqa4S-0000Iy-6m for ecrit@megatron.ietf.org; Thu, 07 Jul 2005 13:21: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 NAA27309 for ; Thu, 7 Jul 2005 13:21:52 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqaVe-0003JT-SK for ecrit@ietf.org; Thu, 07 Jul 2005 13:50:04 -0400 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j67HLY228401 for ; Thu, 7 Jul 2005 13:21:34 -0400 (EDT) Received: from [127.0.0.1] (acart0hc.ca.nortel.com [47.130.24.35]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MRAFRD96; Thu, 7 Jul 2005 13:21:33 -0400 Message-ID: <42CD649A.30606@nortel.com> Date: Thu, 07 Jul 2005 13:21:30 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor 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-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: [Ecrit] Requirement SD1 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 to settle my action on SD1. I've taken the existing text as motivation and added a requirement. SD1 requirement: The format both of the query and of the result returned by the protocol must be extensible. Motivation: In addition to information sent with the call, additional information may be available, supplemental to the call, which is retrieved from internal or external databases using a key to the information included with the call. This key may also include information to identify/address the database. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 08 11:24:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DquiM-0008Pv-MD; Fri, 08 Jul 2005 11:24:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DquiL-0008Pq-D8 for ecrit@megatron.ietf.org; Fri, 08 Jul 2005 11:24:29 -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 LAA19769 for ; Fri, 8 Jul 2005 11:24:27 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqv9j-0000dS-UE for ecrit@ietf.org; Fri, 08 Jul 2005 11:52:49 -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, 8 Jul 2005 11:24:10 -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] WG: Action items needed forI-D:draft-schulzrinne-ecrit-requirements-00.txt Date: Fri, 8 Jul 2005 08:24:09 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657502A74F5F@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] WG: Action items needed forI-D:draft-schulzrinne-ecrit-requirements-00.txt Thread-Index: AcVSfG5supQyJEqRSZGS41N9yJhQXwIyqlzgAB61AZAISQhYEAABAifwAbh79sA= From: "Roger Marshall" To: "Tschofenig Hannes" , "Marc Linsner" , X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 A couple more editing changes to the next version of the ecrit requirements draft, which will be posted shortly: 1. Renaming of the section titled, "Identifying the Appropriate Emergency Call Center" to "Identifying the Appropriate PSAP", based on prior terminology consolidation already agreed to. 2. Reslot those requirements which refer to "the mapping protocol" from the section titled, "Identifying the Caller Location", into the section (now titled) "Identifying the Appropriate PSAP". These requirements will be relabeled as I40, I41, and I42 (originally labeled L9, L31, and L32 and as stated below): L9. The mapping protocol MUST be extensible to allow=20 for the inclusion of new location fields. Motivation: This is needed, for example, to accommodate future=20 extensions to location information that might be included in the=20 PIDF-LO. L31. Split responsibility: The mapping protocol MUST=20 allow that within a single level of the civic address hierarchy, multiple=20 mapping servers handle subsets of the data elements. Motivation: For example, two directories for the same city or county=20 may handle different streets within that city or county. L32. The mapping function MUST be able to be invoked=20 at any time, including while an emergency call is in process. 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 Jul 08 12:49:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqw2S-0004np-Or; Fri, 08 Jul 2005 12:49:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqw2N-0004mK-C8 for ecrit@megatron.ietf.org; Fri, 08 Jul 2005 12:49: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 MAA27458 for ; Fri, 8 Jul 2005 12:49:10 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqwTi-0005Dl-L4 for ecrit@ietf.org; Fri, 08 Jul 2005 13:17:34 -0400 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j68GmfW05395; Fri, 8 Jul 2005 12:48:41 -0400 (EDT) Received: from [127.0.0.1] (acart256.ca.nortel.com [47.130.17.125]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MRAFRJXY; Fri, 8 Jul 2005 12:48:26 -0400 Message-ID: <42CEAE56.6050001@nortel.com> Date: Fri, 08 Jul 2005 12:48:22 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor 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] WG: Action items needed forI-D:draft-schulzrinne-ecrit-requirements-00.txt References: <8C837214C95C864C9F34F3635C2A657502A74F5F@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A657502A74F5F@SEA-EXCHVS-2.telecomsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 We need to differentiate SD1 from L9. I therefore suggest that SD1 be rewritten to say: "The format both of the query and of the result returned by the protocol must be extensible to accommodate new types of information." The motivation can stay the same. Roger Marshall wrote: > A couple more editing changes to the next version of the ecrit > requirements draft, which will be posted shortly: > > > 1. Renaming of the section titled, "Identifying the Appropriate > Emergency Call Center" to "Identifying the Appropriate PSAP", based on > prior terminology consolidation already agreed to. > > 2. Reslot those requirements which refer to "the mapping protocol" from > the section titled, "Identifying the Caller Location", into the section > (now titled) "Identifying the Appropriate PSAP". These requirements > will be relabeled as I40, I41, and I42 (originally labeled L9, L31, and > L32 and as stated below): > > > L9. The mapping protocol MUST be extensible to allow > for the inclusion of new location fields. > > Motivation: This is needed, for example, to accommodate future > extensions to location information that might be included in the > PIDF-LO. > ... _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 08 15:17:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqyLf-000266-HR; Fri, 08 Jul 2005 15:17:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqyLe-00025t-Gl for ecrit@megatron.ietf.org; Fri, 08 Jul 2005 15:17: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 PAA08776 for ; Fri, 8 Jul 2005 15:17: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 1Dqyn4-0002rq-U8 for ecrit@ietf.org; Fri, 08 Jul 2005 15:45:40 -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, 8 Jul 2005 15:16: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] WG: R4 SHOULD or MUST in I-D:draft-schulzrinne-ecrit-requirements-00.txt Date: Fri, 8 Jul 2005 12:16:55 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657502A753A7@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] WG: R4 SHOULD or MUST in I-D:draft-schulzrinne-ecrit-requirements-00.txt Thread-Index: AcVSfG5supQyJEqRSZGS41N9yJhQXwIyqlzgAB61AZAISQhYEAABAifwAbh79sAACNGdUA== From: "Roger Marshall" To: "Tschofenig Hannes" , "Marc Linsner" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 Proposed clarification on R4. I plan to change R4, from the ambiguous SHOULD/MUST language to a "MUST". This change reflects the objective described in the first part of the "Motivation" text. So, the requirement changes FROM: R4. Multiple Modes: Multiple communication modes, including Multimedia data and services SHOULD/MUST be supported. TO: R4. Multiple Modes: Multiple communication modes, including Multimedia data and services MUST be supported. Note: Motivation text is not changed. Motivation: Emergency calling MUST support a variety of media, not just=20 voice and TDD (telecommunication device for the deaf) beyond the=20 capabilities of current limitations. Such additional media should=20 include conversational text, instant messaging and video. In addition, it=20 should be possible to convey telemetry data, such as data from=20 automobile crash sensors. -roger. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jul 09 10:41:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrGWR-0003RG-Im; Sat, 09 Jul 2005 10:41:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrGWQ-0003R9-Of for ecrit@megatron.ietf.org; Sat, 09 Jul 2005 10:41: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 KAA04822 for ; Sat, 9 Jul 2005 10:41:34 -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 1DrGxy-0005z8-Dd for ecrit@ietf.org; Sat, 09 Jul 2005 11:10:08 -0400 Received: from [192.168.0.31] (pool-141-153-198-113.mad.east.verizon.net [141.153.198.113]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j69EfVWM007520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 9 Jul 2005 10:41:32 -0400 (EDT) Message-ID: <42CFE21F.9060605@cs.columbia.edu> Date: Sat, 09 Jul 2005 10:41:35 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Hardie Subject: Re: [Ecrit] simplified R5? References: <42C5F37D.4000304@cs.columbia.edu> 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: 287c806b254c6353fcb09ee0e53bbc5e 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 Ted Hardie wrote: > The point I was making is that topologically distinct allows you to > deal with both local failures and large-scale failure. To flesh this > out: you have power and network connectivity to a DC-powered DSLAM > where the power surge in the CO after your emergency fried all the > AC-powered servers. Having the topologically distinct master server > available means you can still get the mapping done to call for help. > From the client's perspective, what it needs is a list (probably an > ordered list) of servers it can use. From a deployment perspective, > what we need is sensible distribution of the servers--and that can > include many different kinds of replication, including "local cache > of master server", but this is deployment advice, not a protocol > requirement. We clearly need topologically distinct, but 'topologically distinct' doesn't address the locality constraint. Let me try to give an example of a system that satisfies topologically distinct, but would not work well for emergency mapping: Assume the caller placing the 911 call is physically located in Detroit; presumably, the PSAP serving her is in Detroit as well. The ECRIT service provider is in DC, with redundant servers in SF and NY. A disaster strikes and wide-area network connectivity is disrupted. In other words, our caller in Detroit can't get to SF or NY, but can ping the PSAP and route a SIP call there (if she knew where it was). This is not a common scenario for normal Internet service, as local connectivity only isn't particularly useful. (Almost all web sites wouldn't be reachable if there's no wide-area connectivity, even if DNS continues to function.) However, emergency calling is inherently local - most of the interesting, time-critical communication will take place between entities located within a few miles of each other. [There are exceptions in some sparsely populated states, with state-wide PSAPs, but given the number of 6,000 PSAPs in the US, this is pretty close.] As an aside, I suspect that in the future, PSAPs will have direct IP connectivity into the major local ISPs such as the DSL and cable providers, as that avoids having to rely on possibly remote exchange points or peering. In summary: redundant, diverse server setups are necessary, but not sufficient. > > >> As I noted earlier, based on your note, the network path >> includes both the call signaling and the media path. Thus, the MSP >> could just as easily host this server, without endangering fate >> sharing (assuming that it requires an outbound proxy). > > > Sorry, assuming what require an outbound proxy? I think I lost your > point here. The point is that both the ISP and the MSP could operate a caching ECRIT server. There are two cases: (1) The MSP allows direct connections to any SIP address without going through an outbound proxy. (Or there is no MSP as such - another common case.) In that case, the caller could either use the ISPs ECRIT service or some other service. (2) The MSP requires use of its outbound proxy server for all calls. In that case, it would be desirable for the lookup function to reside there as well, to limit exposure to long-distance failures. We don't know how ECRIT will be deployed, but the protocol machinery needs to support highly robust deployment architectures, even if some will choose to run a single server from a trailer park in Florida using IP-over-barbed-wire-fences. > I think you misunderstood me. I'm saying if we *require* the access > provider to handle the infrastructure, it is an unfunded mandate; we > can certainly design so that they *may* provide it, but we also out > to take into account deployments where they do not and someone like > the VSP does. But I don't think we can handle requirements where the > access provider isn't available--if they're not up, the bits don't > flow. I don't think anything I said requires that the access provider runs this service. I don't want to get into unfunded mandates - if this is cheap enough to run, ISPs will offer it just like they offer DNS today, even though they could clearly tell their customers to get their DNS service elsewhere. [In many cases, access providers will also offer VoIP service in any event.] > > Again, I think the protocol requirement here is to be able to handle > multiple, topologically distinct servers. Describing where it is > sensible to keep these multiple copies is useful stuff, but it is not > a protocol requirement. regards, Ted Hardie The problem is that this is not sufficient. I think the requirement that got lost in the discussion thread is the ability to run a *caching* copy of the database. That allows lots and lots of such servers, including those located very close to the subscribers. Thus, I think the location discussion is a bit besides the point; it simply motivates the need for the equivalent of non-authoritative servers, to use DNS terminology. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 11 13:23:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds1zr-0000oP-Kc; Mon, 11 Jul 2005 13:23:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds1zp-0000oF-8Y for ecrit@megatron.ietf.org; Mon, 11 Jul 2005 13:23: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 NAA02962 for ; Mon, 11 Jul 2005 13:23:06 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds2Rn-0000hr-N6 for ecrit@ietf.org; Mon, 11 Jul 2005 13:52:08 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6BHMUdd029659; Mon, 11 Jul 2005 10:22:30 -0700 (PDT) Received: from [192.168.1.4] (carbuncle.qualcomm.com [129.46.227.161]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6BHMRRq000434; Mon, 11 Jul 2005 10:22:28 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <42CFE21F.9060605@cs.columbia.edu> References: <42C5F37D.4000304@cs.columbia.edu> <42CFE21F.9060605@cs.columbia.edu> Date: Mon, 11 Jul 2005 10:22:26 -0700 To: Henning Schulzrinne From: Ted Hardie Subject: Re: [Ecrit] simplified R5? Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 At 10:41 AM -0400 7/9/05, Henning Schulzrinne wrote: >T > >We clearly need topologically distinct, but 'topologically distinct' doesn't address the locality constraint. Let me try to give an example of a system that satisfies topologically distinct, but would not work well for emergency mapping: > >Assume the caller placing the 911 call is physically located in Detroit; presumably, the PSAP serving her is in Detroit as well. > >The ECRIT service provider is in DC, with redundant servers in SF and NY. A disaster strikes and wide-area network connectivity is disrupted. In other words, our caller in Detroit can't get to SF or NY, but can ping the PSAP and route a SIP call there (if she knew where it was). > >This is not a common scenario for normal Internet service, as local connectivity only isn't particularly useful. (Almost all web sites wouldn't be reachable if there's no wide-area connectivity, even if DNS continues to function.) However, emergency calling is inherently local - most of the interesting, time-critical communication will take place between entities located within a few miles of each other. [There are exceptions in some sparsely populated states, with state-wide PSAPs, but given the number of 6,000 PSAPs in the US, this is pretty close.] > >As an aside, I suspect that in the future, PSAPs will have direct IP connectivity into the major local ISPs such as the DSL and cable providers, as that avoids having to rely on possibly remote exchange points or peering. I don't disagree with the scenario at all. But the locality of the server doesn't change the protocol mechanism. The system needs to provide a set of weighted or ordered alternate servers for this mechanism so that someone can try to reach the alternates in the emergency. The system trying to make the emergency contact shouldn't need to understand either the topology or the locality of the servers it's trying to reach--it's just working off an annotated list. So I think your scenario would be a very useful addition to a deployment doc, explaining why you want both topological distinct servers and locality, but I don't see a *protocol* requirement here other than "support topologically distinct servers" and "provide a mechanism for preference among available servers (e.g. weighting or ordering)". > >The problem is that this is not sufficient. I think the requirement that got lost in the discussion thread is the ability to run a *caching* copy of the database. That allows lots and lots of such servers, including those located very close to the subscribers. > >Thus, I think the location discussion is a bit besides the point; it simply motivates the need for the equivalent of non-authoritative servers, to use DNS terminology. > And I think the *caching* aspect is one where we do have disagreements. Caching is one data replication technology, but it is far from the only one and it isn't clear that its characteristics are a good match for this problem space. If you do pull-based caching (a la the DNS or HTTP caching proxies), you have to worry about cache freshness, appropriate cache size, and other aspects of the algorithm for cache ejection. If you are not doing demand-based cache population, you may also have to worry about how the traffic for refreshing cache entries competes with the traffic for emergencies. If you are thinking of the DNS, you should note that not only did demand-based cache population not get used for "slave" authoritative servers, there are at least two common technologies for populating those--AXFR and rsynch, with backend SQL servers' replication a likely third. Before going down the caching road to far, to what extent do you perceive the need for a *local* server to combine data from multiple sources, and what numbers of sources are we talking about here? Are we expecting the local servers to have any trust relationships with the authoritative sources? regards, Ted Hardie _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 11 21:59:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsA3A-0000xx-35; Mon, 11 Jul 2005 21:59:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsA38-0000xs-DR for ecrit@megatron.ietf.org; Mon, 11 Jul 2005 21:59: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 VAA15398 for ; Mon, 11 Jul 2005 21:59:04 -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 1DsAVF-0005Sd-MP for ecrit@ietf.org; Mon, 11 Jul 2005 22:28:09 -0400 Received: from [192.168.0.31] (pool-141-153-198-113.mad.east.verizon.net [141.153.198.113]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j6C1x4Gg015965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Jul 2005 21:59:05 -0400 (EDT) Message-ID: <42D323E6.1000909@cs.columbia.edu> Date: Mon, 11 Jul 2005 21:59:02 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Hardie Subject: Re: [Ecrit] simplified R5? References: <42C5F37D.4000304@cs.columbia.edu> <42CFE21F.9060605@cs.columbia.edu> 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: 8b431ad66d60be2d47c7bfeb879db82c 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 Ted Hardie wrote: > I don't disagree with the scenario at all. But the locality of the > server doesn't change the protocol mechanism. The system needs to > provide a set of weighted or ordered alternate servers for this > mechanism so that someone can try to reach the alternates in the > emergency. The system trying to make the emergency contact shouldn't > need to understand either the topology or the locality of the servers > it's trying to reach--it's just working off an annotated list. Indirectly, it does affect the operation. There are likely to be thousands of ISPs, MSPs and MSP-like organizations (i.e., organizations that provide VoIP services to their users, but don't sell the service to the public, such as most mid- to large-size enterprises and institutions). Reliability is increased significantly if these organizations can provide service locally, even if they are not at all authoritative for the data. This probably got lost in the discussion before, since I kind of assumed this, but I get the feeling that some participants in this discussion have a very different deployment model, namely one of a paid service more akin to a very reliable phone directory that you contact after obtaining a contract. ("Hi, directory assistance, what's the number for the police department in Smithville?"). Thus, maybe the more important consideration is not as much the precise placement, but the ability to place lots of mapping servers close to the user, operated by a variety of entities that may only have a loose association with the source of the data. (This describes, at a high level, the DNS model, I think.) I don't know if deployments will develop in that direction, but I'd rather not prejudge business models and rule out such distributed arrangements by limiting protocol capabilities. Some people who have been involved in the 911 stuff for a while have seen what logically centralized directories do to competition and pricing. > > So I think your scenario would be a very useful addition to a > deployment doc, explaining why you want both topological distinct > servers and locality, but I don't see a *protocol* requirement here > other than "support topologically distinct servers" and "provide a > mechanism for preference among available servers (e.g. weighting or > ordering)". See above - it's more than weighting or physical distribution. Indeed, in the model of highly distributed servers, there is no central place to go ask for weights, lists of servers or anything else. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 11 22:16:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsAEq-0005JL-OS; Mon, 11 Jul 2005 22:11:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsAEp-0005JG-NP for ecrit@megatron.ietf.org; Mon, 11 Jul 2005 22:11: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 WAA16134 for ; Mon, 11 Jul 2005 22:11:09 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsAgw-0005qv-4d for ecrit@ietf.org; Mon, 11 Jul 2005 22:40:15 -0400 Received: from [10.0.1.2] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Mon, 11 Jul 2005 22:11:01 -0400 id 00213E17.42D326B6.00006D6E In-Reply-To: <42D323E6.1000909@cs.columbia.edu> References: <42C5F37D.4000304@cs.columbia.edu> <42CFE21F.9060605@cs.columbia.edu> <42D323E6.1000909@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4E051C1C-8440-4B12-AFA0-ABC6AF7A6536@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] simplified R5? Date: Mon, 11 Jul 2005 22:10:57 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.730) 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 On Jul 11, 2005, at 9:59 PM, Henning Schulzrinne wrote: > organizations that provide VoIP services to their users, but don't > sell the service to the public, such as most mid- to large-size > enterprises and institutions Let me see. My options are to buy two servers, each with dual power supplies and hot-swappable RAID, and the on-going expense of an admin to keep the boxes up, OR gateway 911 calls to the PSTN for free. Decisions. Decisions. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 11 22:17:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsAKf-0006bZ-Kx; Mon, 11 Jul 2005 22:17:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsAKe-0006bU-A6 for ecrit@megatron.ietf.org; Mon, 11 Jul 2005 22:17: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 WAA16565 for ; Mon, 11 Jul 2005 22:17:10 -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 1DsAmj-00062s-MD for ecrit@ietf.org; Mon, 11 Jul 2005 22:46:15 -0400 Received: from [192.168.0.31] (pool-141-153-198-113.mad.east.verizon.net [141.153.198.113]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j6C2H6Rp005781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Jul 2005 22:17:06 -0400 (EDT) Message-ID: <42D32820.8080203@cs.columbia.edu> Date: Mon, 11 Jul 2005 22:17:04 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] simplified R5? References: <42C5F37D.4000304@cs.columbia.edu> <42CFE21F.9060605@cs.columbia.edu> <42D323E6.1000909@cs.columbia.edu> <4E051C1C-8440-4B12-AFA0-ABC6AF7A6536@hxr.us> In-Reply-To: <4E051C1C-8440-4B12-AFA0-ABC6AF7A6536@hxr.us> 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: 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 Andrew Newton wrote: > > On Jul 11, 2005, at 9:59 PM, Henning Schulzrinne wrote: > >> organizations that provide VoIP services to their users, but don't >> sell the service to the public, such as most mid- to large-size >> enterprises and institutions > > > Let me see. My options are to buy two servers, each with dual power > supplies and hot-swappable RAID, and the on-going expense of an admin > to keep the boxes up, OR gateway 911 calls to the PSTN for free. > Decisions. Decisions. Thanks for raising the level of discussion. Except that gatewaying to the PSTN for 911 is not a viable option if my customers live outside the service area of a single PSAP. Think any service provider with a national footprint (Skype, Vonage). The current option for MSPs with regional coverage is to go provide or buy gateway access to about 2,000 selective routers in the US, while still not offering number portability, mobility and other services. I'll ignore the fact that there won't be a PSTN service as such at some point in the future, hopefully while the ECRIT protocol is still in use. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 11 22:37:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsAeK-0005GM-Mj; Mon, 11 Jul 2005 22:37:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsAeJ-0005GC-FG for ecrit@megatron.ietf.org; Mon, 11 Jul 2005 22:37: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 WAA17345 for ; Mon, 11 Jul 2005 22:37:29 -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 1DsB6Q-0006Y8-SZ for ecrit@ietf.org; Mon, 11 Jul 2005 23:06:35 -0400 Received: from [192.168.0.31] (pool-141-153-198-113.mad.east.verizon.net [141.153.198.113]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j6C2bSek027907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Jul 2005 22:37:29 -0400 (EDT) Message-ID: <42D32CE7.7020806@cs.columbia.edu> Date: Mon, 11 Jul 2005 22:37:27 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Hardie Subject: Re: [Ecrit] simplified R5? References: <42C5F37D.4000304@cs.columbia.edu> <42CFE21F.9060605@cs.columbia.edu> 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: 6d95a152022472c7d6cdf886a0424dc6 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 Ted Hardie wrote: > And I think the *caching* aspect is one where we do have > disagreements. Caching is one data replication technology, but it is > far from the only one and it isn't clear that its characteristics are > a good match for this problem space. If you do pull-based caching (a > la the DNS or HTTP caching proxies), you have to worry about cache > freshness, appropriate cache size, and other aspects of the algorithm > for cache ejection. If you are not doing demand-based cache > population, you may also have to worry about how the traffic for > refreshing cache entries competes with the traffic for emergencies. Sure, but as I indicated in earlier iterations of this discussions, these problems are all likely to be significantly easier than for either HTTP or DNS, even under very extreme assumptions. (The number of data elements is much smaller, there is much more locality and relatively little change.) Thus, I believe that very good cache hit ratios can be achieved. I had provided a number of ways that this could be made to work earlier, but this isn't really the time to go through those. Clearly, these mechanisms need to be designed, but do you see a fundamental problem that prevents the use of caching in this application? At the requirement level, caching isn't really the issue, but the distributed administration. > > If you are thinking of the DNS, you should note that not only did > demand-based cache population not get used for "slave" authoritative > servers, there are at least two common technologies for populating > those--AXFR and rsynch, with backend SQL servers' replication a > likely third. There are two separate problems here that are getting somewhat commingled: Synchronization of authoritative servers and local caching. These are distinct problems, with likely somewhat different solutions. (Synchronization needs to ensure that the two data stores are exactly the same; caching only optimizes retrievals and can work probabilistically.) Just because some people use rsynch and SQL server replication doesn't mean that having DNS offer AXFR was a bad idea or shouldn't have been done. There will always be locally optimal mechanisms that aren't standardized, but we need to provide protocol mechanisms that work well in lots of circumstances, without a "and to really make this reliable, you have to agree on some proprietary mechanism since we couldn't be bothered to specify the hard stuff". I certainly would never claim that we would prescribe how synchronization should always be done, but there are strong advantages to having a minimal level of interoperability between organizations that do things, for example, on a mutual-aid basis. > > Before going down the caching road to far, to what extent do you > perceive the need for a *local* server to combine data from multiple > sources, and what numbers of sources are we talking about here? Are > we expecting the local servers to have any trust relationships with > the authoritative sources? regards, Ted Hardie Back-of-an-envelope calculation: There are 1.2 million companies with 50 to 250 workers [http://seattlepi.nwsource.com/business/231746_msftsales08.html, courtesy of random googling]. Each one is likely to eventually have a VoIP system if they have other network infrastructure. It should be possible that each one of these runs a local ECRIT server, as they are likely to run a DNS or mail server. Clearly, there are thousands of ISPs, almost all of whom are likely to either offer or resell VoIP service. The number of sources can vary. One reasonable deployment model is that you'd have each PSAP advertise its own coverage region, making for about 6,000 sources in the US. That number seems unlikely, but is probably a useful upper bound. Obviously, each of the midsize companies would mostly care about information for its own geographic area (say, the 20 restaurants that it operates as a franchisee in a metro area), not the whole US. It might possibly care about the home locations of its workers, as they might VPN in from home. The number of entries in any local cache would be small (maybe a few hundred for the companies I mentioned above). In a distributed model, I would expect the servers to have some kind of trust relationship with the authoritative servers, but this could be something simple, such as some kind of capability cert in TLS ("Hi, I'm a government-certified PSAP advertiser"). There are other alternatives, e.g., where trust is established on a per-data item level, but I'd rather not engineer a solution at this point since this tends to just lead to micro-critiques of the solution rather than requirement discussion. As far as I can tell, this issue is also relatively independent of the fact that there'd be a caching hierarchy. But, going back to my earlier question, maybe the model in some discussant's mind is that a single company runs the server farm, say, on a country-wide basis, and users would only connect to one of those servers. (Or, similarly, a small number of such companies that users would contract with and that use some non-standardized means to populate their own complete mapping database from PSAP information.) It might be helpful to bring out those assumptions, since they may color our design assumptions and what one might consider reasonable requirements. This might be more illuminating than costing RAID arrays. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 11 22:49:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsAqK-000108-8x; Mon, 11 Jul 2005 22:49:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsAqH-0000zl-HE for ecrit@megatron.ietf.org; Mon, 11 Jul 2005 22:49: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 WAA18088 for ; Mon, 11 Jul 2005 22:49:51 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsBIO-0006tL-8K for ecrit@ietf.org; Mon, 11 Jul 2005 23:18:57 -0400 Received: from [10.0.1.2] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Mon, 11 Jul 2005 22:49:50 -0400 id 00213E17.42D32FCE.0000742A In-Reply-To: <42D32820.8080203@cs.columbia.edu> References: <42C5F37D.4000304@cs.columbia.edu> <42CFE21F.9060605@cs.columbia.edu> <42D323E6.1000909@cs.columbia.edu> <4E051C1C-8440-4B12-AFA0-ABC6AF7A6536@hxr.us> <42D32820.8080203@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] simplified R5? Date: Mon, 11 Jul 2005 22:49:47 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 Jul 11, 2005, at 10:17 PM, Henning Schulzrinne wrote: > Thanks for raising the level of discussion. Oh, I think its a fair question. In all this, you have outlined some pretty serious requirements with some pretty serious liabilities should something go wrong... all of this being placed upon small and medium sized businesses wishing to take advantage of VoIP. > Except that gatewaying to the PSTN for 911 is not a viable option > if my customers live outside the service area of a single PSAP. > Think any service provider with a national footprint (Skype, Vonage). You've changed the subject... but highlighted one of the concerns Ted mentioned. Do Skype and Vonage run the layer 2 network, the DHCP servers, and the DNS servers? I'm sure the access providers are happy to sell me access so I can use Vonage, but I'm sure they will be unhappy to take on the liability you have outlined if they aren't receiving any compensation. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 11 23:00:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsB0U-0004t9-Sl; Mon, 11 Jul 2005 23:00:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsB0L-0004q7-5D for ecrit@megatron.ietf.org; Mon, 11 Jul 2005 23:00: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 XAA19257 for ; Mon, 11 Jul 2005 23:00:14 -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 1DsBSQ-0007Lm-Ud for ecrit@ietf.org; Mon, 11 Jul 2005 23:29:21 -0400 Received: from [192.168.0.31] (pool-141-153-198-113.mad.east.verizon.net [141.153.198.113]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j6C30Cp8010176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Jul 2005 23:00:12 -0400 (EDT) Message-ID: <42D3323C.2060107@cs.columbia.edu> Date: Mon, 11 Jul 2005 23:00:12 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] simplified R5? References: <42C5F37D.4000304@cs.columbia.edu> <42CFE21F.9060605@cs.columbia.edu> <42D323E6.1000909@cs.columbia.edu> <4E051C1C-8440-4B12-AFA0-ABC6AF7A6536@hxr.us> <42D32820.8080203@cs.columbia.edu> 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: 7aafa0432175920a4b3e118e16c5cb64 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 Andrew, I don't think discussing business models is particularly productive here. Neither of us knows that the deployment architecture will look like, but I don't want to lock us into one model, even if there are vendors participating in the working group who might be more than happy to take the load and liability of the ISPs or MSPs shoulders, for a fee. As to your second remark, this has nothing to do with the choices ISPs make. The same discussion holds if MSPs or businesses want to run ECRIT services. Besides, the distinction between ISP and VSP will be organizationally moot, in that most ISPs are likely to also offer VSP services unless prohibited by a regulator. Thus, the only likely question is whether they'll restrict the ECRIT service to their own VSP customers and whether regulators will allow that. But I'm not sure that crystal-ball gazing is particularly productive here as, short of time travel, we won't be able to conclude this discussion. The pertinent protocol discussion is whether the ECRIT protocol design needs to support an organizationally distributed model, even if we can't predict for sure that this will be the deployment model. If we don't engineer for this, we have decided the deployment and business model, just like the limitations of the existing MSAG and ALI technology have decided the business model for CLECs and I1 offerings in the United States. Henning Andrew Newton wrote: > > On Jul 11, 2005, at 10:17 PM, Henning Schulzrinne wrote: > >> Thanks for raising the level of discussion. > > > Oh, I think its a fair question. In all this, you have outlined some > pretty serious requirements with some pretty serious liabilities should > something go wrong... all of this being placed upon small and medium > sized businesses wishing to take advantage of VoIP. > >> Except that gatewaying to the PSTN for 911 is not a viable option if >> my customers live outside the service area of a single PSAP. Think >> any service provider with a national footprint (Skype, Vonage). > > > You've changed the subject... but highlighted one of the concerns Ted > mentioned. Do Skype and Vonage run the layer 2 network, the DHCP > servers, and the DNS servers? I'm sure the access providers are happy > to sell me access so I can use Vonage, but I'm sure they will be > unhappy to take on the liability you have outlined if they aren't > receiving any compensation. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 12 00:07:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsC3K-0001BW-VJ; Tue, 12 Jul 2005 00:07:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsC3K-0001BR-Du for ecrit@megatron.ietf.org; Tue, 12 Jul 2005 00:07: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 AAA23371 for ; Tue, 12 Jul 2005 00:07:23 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsCVQ-00010Z-Hn for ecrit@ietf.org; Tue, 12 Jul 2005 00:36:31 -0400 Received: from [10.0.1.2] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Tue, 12 Jul 2005 00:07:19 -0400 id 00213E18.42D341F8.000003B5 In-Reply-To: <42D3323C.2060107@cs.columbia.edu> References: <42C5F37D.4000304@cs.columbia.edu> <42CFE21F.9060605@cs.columbia.edu> <42D323E6.1000909@cs.columbia.edu> <4E051C1C-8440-4B12-AFA0-ABC6AF7A6536@hxr.us> <42D32820.8080203@cs.columbia.edu> <42D3323C.2060107@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <242B5B7E-94E0-4B44-9A0F-02BAA9909DD7@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] simplified R5? Date: Tue, 12 Jul 2005 00:07:15 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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 Henning, Like you, I do not think it is productive to discuss business models. Nor do I think either of us knows what the deployment architecture will look like. And like you, I do not want to lock us into one model, especially one dictated by semantics in a protocol that cannot possibly be designed without knowledge of the deployed architecture. I have simply asked clarifying questions regarding caches and database replication that you have asserted are part of the R5 item titled "Minimum Connectivity". If such a requirement is to be given, its meaning must be well understood. Yet the assertions given regarding this requirement are not well understood. The pertinent protocol discussion is whether or not the ECRIT protocol needs to have semantics for database replication in a query that uses location as a parameter in order to acquire a URI. As you have stated, we cannot predict the deployment model. Therefore, we should not burden this query with any semantics for database replication as they may not match the model that will be deployed. This is especially true given that there is no certainty against replication via other means. -andy On Jul 11, 2005, at 11:00 PM, Henning Schulzrinne wrote: > Andrew, > > I don't think discussing business models is particularly productive > here. Neither of us knows that the deployment architecture will > look like, but I don't want to lock us into one model, even if > there are vendors participating in the working group who might be > more than happy to take the load and liability of the ISPs or MSPs > shoulders, for a fee. > > As to your second remark, this has nothing to do with the choices > ISPs make. The same discussion holds if MSPs or businesses want to > run ECRIT services. Besides, the distinction between ISP and VSP > will be organizationally moot, in that most ISPs are likely to also > offer VSP services unless prohibited by a regulator. Thus, the only > likely question is whether they'll restrict the ECRIT service to > their own VSP customers and whether regulators will allow that. > > But I'm not sure that crystal-ball gazing is particularly > productive here as, short of time travel, we won't be able to > conclude this discussion. > > The pertinent protocol discussion is whether the ECRIT protocol > design needs to support an organizationally distributed model, even > if we can't predict for sure that this will be the deployment > model. If we don't engineer for this, we have decided the > deployment and business model, just like the limitations of the > existing MSAG and ALI technology have decided the business model > for CLECs and I1 offerings in the United States. > > Henning > > Andrew Newton wrote: > >> On Jul 11, 2005, at 10:17 PM, Henning Schulzrinne wrote: >> >>> Thanks for raising the level of discussion. >>> >> Oh, I think its a fair question. In all this, you have outlined >> some pretty serious requirements with some pretty serious >> liabilities should something go wrong... all of this being placed >> upon small and medium sized businesses wishing to take advantage >> of VoIP. >> >>> Except that gatewaying to the PSTN for 911 is not a viable >>> option if my customers live outside the service area of a single >>> PSAP. Think any service provider with a national footprint >>> (Skype, Vonage). >>> >> You've changed the subject... but highlighted one of the concerns >> Ted mentioned. Do Skype and Vonage run the layer 2 network, the >> DHCP servers, and the DNS servers? I'm sure the access providers >> are happy to sell me access so I can use Vonage, but I'm sure >> they will be unhappy to take on the liability you have outlined >> if they aren't receiving any compensation. >> -andy >> > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 12 08:21:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsJlr-0003n3-8v; Tue, 12 Jul 2005 08:21:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsJlp-0003mv-UN for ecrit@megatron.ietf.org; Tue, 12 Jul 2005 08:21: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 IAA15945 for ; Tue, 12 Jul 2005 08:21:53 -0400 (EDT) Message-Id: <200507121221.IAA15945@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsKE2-0001ac-MH for ecrit@ietf.org; Tue, 12 Jul 2005 08:51:02 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41xp) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DsJlX-0005o2-24; Tue, 12 Jul 2005 07:21:35 -0500 From: "Brian Rosen" To: "'Andrew Newton'" , "'Henning Schulzrinne'" Subject: RE: [Ecrit] simplified R5? Date: Tue, 12 Jul 2005 08:21:28 -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.2527 Thread-Index: AcWGjMWuJwu8/lV8TTeivnoTeWLqLgAThKZg In-Reply-To: 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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 Businesses that have a "single" IP-PBX and deploy teleworkers with phones that are served by that single system, or who have multiple sites that are served from one gateway for calls to the PSTN have the problem that they have to direct 9-1-1 calls somewhere other than where there PSTN connection could get them. Their current liability is pretty large if they deploy such systems, because they don't work, and they know they don't work. A similar argument, with other implications, occurs with a road warrior, where the call routing element is half a world away. I think Henning is quite right; there must be mechanisms to provide mapping information where there are no prior arrangements -- the source of the authoritative mapping information has no relationship with the call routing element, and these must work when there are large disruptions to the Internet. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Andrew Newton Sent: Monday, July 11, 2005 10:50 PM To: Henning Schulzrinne Cc: ecrit@ietf.org Subject: Re: [Ecrit] simplified R5? On Jul 11, 2005, at 10:17 PM, Henning Schulzrinne wrote: > Thanks for raising the level of discussion. Oh, I think its a fair question. In all this, you have outlined some pretty serious requirements with some pretty serious liabilities should something go wrong... all of this being placed upon small and medium sized businesses wishing to take advantage of VoIP. > Except that gatewaying to the PSTN for 911 is not a viable option > if my customers live outside the service area of a single PSAP. > Think any service provider with a national footprint (Skype, Vonage). You've changed the subject... but highlighted one of the concerns Ted mentioned. Do Skype and Vonage run the layer 2 network, the DHCP servers, and the DNS servers? I'm sure the access providers are happy to sell me access so I can use Vonage, but I'm sure they will be unhappy to take on the liability you have outlined if they aren't receiving any compensation. -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 Tue Jul 12 18:08:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsSvV-0002RM-1z; Tue, 12 Jul 2005 18:08:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsSvS-0002RB-MF; Tue, 12 Jul 2005 18:08: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 SAA23290; Tue, 12 Jul 2005 18:08:24 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsTNj-0007LC-IT; Tue, 12 Jul 2005 18:37:40 -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 j6CM8MOn008728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Jul 2005 18:08:23 -0400 (EDT) Message-ID: <42D43F51.4010609@cs.columbia.edu> Date: Tue, 12 Jul 2005 18:08:17 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping , 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: Subject: [Ecrit] 'service' URN 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.ietf.org/internet-drafts/draft-schulzrinne-sipping-service-00.txt (or prettier at http://www.cs.columbia.edu/sip/draft/service/draft-schulzrinne-sipping-service-00.html) is an initial attempt to solve an identification problem, namely how to identify services that have different instantiations depending on the location of the entity requesting the service. Emergency calling is the best-known instance of this problem or service, but there are many more, from "311" (general government services in large cities) to the AAA SuperNumber for towing services. Comments as to the general approach are particularly appreciated. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 12 19:06:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsTq2-0001GT-Ml; Tue, 12 Jul 2005 19:06:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsTq0-0001FL-08; Tue, 12 Jul 2005 19:06: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 TAA01807; Tue, 12 Jul 2005 19:06:48 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsUIH-00025t-2T; Tue, 12 Jul 2005 19:36:05 -0400 Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Tue, 12 Jul 2005 19:06:49 -0400 id 00117D0A.42D44D09.00004141 In-Reply-To: <42D43F51.4010609@cs.columbia.edu> References: <42D43F51.4010609@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <11BF9D21-F4DF-418C-899B-27B53FEF8DA4@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] 'service' URN Date: Tue, 12 Jul 2005 19:06:35 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: sipping , 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 Jul 12, 2005, at 6:08 PM, Henning Schulzrinne wrote: > Comments as to the general approach are particularly appreciated. Well, a few questions rather than comments. Why a URN registry? What does that offer that a list of well-known service identifiers does not? What am I expecting to get if I plug in urn:service:sos.fire into my URN resolver? Should it be a URLs pointing to a web page about the "sos.fire" identifier? Or is it URLs to all the mapping services of the world that service "sos.fire"? Is this approach meant to make countries with unique emergency identifiers register those identifiers in a global registry? If not, then are you expecting "adhoc URNs" in the service NID? I know you put TBD for the namespace registrant, but who did you have in mind that would run this NID? Is it the ITU? And what rules are they willing to use to insure that identifiers with duplicate meaning are not registered? Such as a particularly stubborn government wishing to register their national languages equivalent to "police". -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 12 19:28:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsUB9-0003el-6H; Tue, 12 Jul 2005 19:28:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsUB7-0003ed-1P for ecrit@megatron.ietf.org; Tue, 12 Jul 2005 19:28: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 TAA07614 for ; Tue, 12 Jul 2005 19:28:38 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsUdP-0004GA-B7 for ecrit@ietf.org; Tue, 12 Jul 2005 19:57:55 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6CNSPQg010606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 12 Jul 2005 16:28:26 -0700 (PDT) Received: from [192.168.1.4] (vpn-10-50-16-65.qualcomm.com [10.50.16.65]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6CNSIRs004835 for ; Tue, 12 Jul 2005 16:28:24 -0700 (PDT) Mime-Version: 1.0 Message-Id: Date: Tue, 12 Jul 2005 16:28:17 -0700 To: ecrit@ietf.org From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Subject: [Ecrit] deployment (was R:5) 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 Henning is right that we may have multiple models of deployment in mind, and that both Andy and Henning are right in saying that we can't mandate or assume too much about the deployment. But I think there are a few questions that we need to have some explicit statements about in order to avoid optimizing for the wrong cases. We've all agreed that the mapping step may occur at multiple points in the call flow. For the case where the mapping step occurs on a caller's behalf at a SIP proxy server (or similar for other contact protocols), I believe we can agree that the proxy server probably won't be talking to a mapping server associated with the caller's access provider unless the access provider is also the voice services provider. Instead, I believe, the proxy server will talk either to a mapping server maintained by its own organization or to the servers of the organization that is the source of the mapping data. So here's my assumption one: the source of the mapping data runs one or more mapping servers, and these are available for querying. This is necessary for cache-fill replication, and it makes sense for local mapping servers that have to mix data from multiple sources. It also provides a "default" server to query when a local mapping server isn't available (either because it isn't provided or beause it's down during the emergency). It isn't strictly necessary from a protocol standpoint, since other servers can serve replicated data derived from other replication mechanisms, but I think we should optimize for the case where this is true. In the proxy server case, a voice service provider's mapping server will likely need to mix data derived from multiple mapping sources. This will be true whenever the organization's service boundaries cross those of mapping sources (certainly true for multi-national and multi-State U.S. service providers, and likely true at even smaller units). Note that there is no protocol requirement that it get that data using the same query protocol used by the caller; it's very likely to be more efficient to get it by other means, either in an extension to the protocol or through some other data transfer protocol. Put another way, data replication is a systemic requirement, not a requirement for the query protocol itself. For the case in which the mapping step occurs prior to the call flow being initiated, the caller may contact a mapping server associated with the voice services provider, one associated with the source of the mapping data, one associated with an access provider, or one associated with some other party (in some countries, for example, the government may run local mapping servers on behalf of the public good). The caller can, of course, only contact a mapping server that it knows about and is reachable. Here's my assumption two: callers will have multiple ways to derive knowledge about available mapping servers. They may have one configured by their voice services provider. They may learn one via DHCP from an access provider. They may be able to locate the mapping server from something like slp if they are querying in advance of need. As part of this assumption, I assume that any mapping server they reach can provide a referral to the correct server to query if it does not have the data locally; alternatively, it may query on behalf of the client and return the data. For both cases, I believe we need to optimize for the situation in which the caller has no data at all about emergency response URIs. There are other cases where the data is stale or not known to correspond to the current location, but we're optimizing for the case where the caller needs something to start with. I also believe we're talking about data where freshness is measured in large numbers of minutes. I believe if we go down to seconds (even in large numbers), we run the risk of the call not completing before the information is stale; that's bad. If we measure in minutes we can handle the common case (reasonably long-lived), but also handle the case where it needs to be shortened in order to handle a transition. In the DNS, for example, the common case is TTLs on the order of three days, but these are shortened prior to changes to short times (e.g. 15 minutes), so that the extant data ages out of cacches and is refreshed with long-lived data once the transition occurs. A mechanism to allow pre-fetch of data before it is "live" is even better here, since it replicates the data without waiting until it is known stale. This reinforces the point that the mechanism to query for current state and the mechanism for keep server replicas up to date do not need to be the same, since this is protocol element not interesting to the caller's mapping query interface. I realize that many elements of this data do not change over very long periods (years, as I understand it, for one common case), but I don't believe that means we should measure in days or weeks. If reasonably possible, we need to get fresh data to the user and or server of replicated date. That means taking a minor hit on network traffic to increase the possibility the data is good; it's a tradeoff but I think its the right one. On another "taking a hit" front, I think we have to rule out any requirement that the system provide a mechanism for winnowing data sets; if a replicated server has to have full data sets available in order to provide the data it needs, it may need to take the hit in terms of data storage and indexing. The number of potential database views is, after all, practically infinite, and burdening the authoritative source with the ability to generate them is onerous whatever the transfer mechanism may be. There are clearly other assumptions we could tease apart here, but I thought I'd start from these and get others' reactions. regards, Ted Hardie _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 12 21:53:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsWQt-00018S-Ox; Tue, 12 Jul 2005 21:53:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsWQs-00018I-Md for ecrit@megatron.ietf.org; Tue, 12 Jul 2005 21:53: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 VAA15985 for ; Tue, 12 Jul 2005 21:53:05 -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 1DsWtB-0008PW-Fu for ecrit@ietf.org; Tue, 12 Jul 2005 22:22:22 -0400 Received: from [192.168.0.31] (pool-141-153-198-113.mad.east.verizon.net [141.153.198.113]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j6D1qu7Y001279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Jul 2005 21:52:58 -0400 (EDT) Message-ID: <42D473C4.4090400@cs.columbia.edu> Date: Tue, 12 Jul 2005 21:52:04 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] simplified R5? References: <42C5F37D.4000304@cs.columbia.edu> <42CFE21F.9060605@cs.columbia.edu> <42D323E6.1000909@cs.columbia.edu> <4E051C1C-8440-4B12-AFA0-ABC6AF7A6536@hxr.us> <42D32820.8080203@cs.columbia.edu> <42D3323C.2060107@cs.columbia.edu> <242B5B7E-94E0-4B44-9A0F-02BAA9909DD7@hxr.us> In-Reply-To: <242B5B7E-94E0-4B44-9A0F-02BAA9909DD7@hxr.us> 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: c1c65599517f9ac32519d043c37c5336 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 Andrew, I'm afraid I don't follow the logic. Your restriction only allows one set of business model, thus restricting the ability to support others, including those where equivalent ones are well-developed in semantically related contexts. Any particular protocol use can easily drop whatever features are unnecessary for their particular deployment model. If you omit certain crucial features, however, you have prevented these architectures from existing. I have no objection to you believing your particular network architecture does not need replication (or caching); I do have a problem you wanting to prevent others from designing what they believe is a reasonably complete protocol that can be inherently reliable by design, rather than non-standard external conventions that essentially prevent loosely-coupled associations. By analogy: We don't say that since there are many possible security architectures, crypto algorithms and the like and since not all implementations will need or want crypto, that we don't specify a minimum set of security mechanisms. Henning Andrew Newton wrote: > Henning, > > Like you, I do not think it is productive to discuss business models. > Nor do I think either of us knows what the deployment architecture will > look like. And like you, I do not want to lock us into one model, > especially one dictated by semantics in a protocol that cannot possibly > be designed without knowledge of the deployed architecture. > > I have simply asked clarifying questions regarding caches and database > replication that you have asserted are part of the R5 item titled > "Minimum Connectivity". If such a requirement is to be given, its > meaning must be well understood. Yet the assertions given regarding > this requirement are not well understood. > > The pertinent protocol discussion is whether or not the ECRIT protocol > needs to have semantics for database replication in a query that uses > location as a parameter in order to acquire a URI. As you have stated, > we cannot predict the deployment model. Therefore, we should not > burden this query with any semantics for database replication as they > may not match the model that will be deployed. This is especially true > given that there is no certainty against replication via other means. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 12 22:05:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsWci-0001eR-7c; Tue, 12 Jul 2005 22:05:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsWch-0001cY-5w; Tue, 12 Jul 2005 22:05: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 WAA16743; Tue, 12 Jul 2005 22:05:17 -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 1DsX51-0000JO-3r; Tue, 12 Jul 2005 22:34:35 -0400 Received: from [192.168.0.31] (pool-141-153-198-113.mad.east.verizon.net [141.153.198.113]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j6D25Gjb002331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Jul 2005 22:05:16 -0400 (EDT) Message-ID: <42D476AA.6020906@cs.columbia.edu> Date: Tue, 12 Jul 2005 22:04:26 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] 'service' URN References: <42D43F51.4010609@cs.columbia.edu> <11BF9D21-F4DF-418C-899B-27B53FEF8DA4@hxr.us> In-Reply-To: <11BF9D21-F4DF-418C-899B-27B53FEF8DA4@hxr.us> 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: sipping , 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 Andrew Newton wrote: > On Jul 12, 2005, at 6:08 PM, Henning Schulzrinne wrote: > >> Comments as to the general approach are particularly appreciated. > > > Well, a few questions rather than comments. Thanks for taking the time to read the document. Let me try some answers. > > Why a URN registry? What does that offer that a list of well-known > service identifiers does not? Primarily, the ability to use these identifiers where URLs or URNs are required or useful, such as SIP request URIs, web pages or the responses from multi-stage mapping protocols, such as those we are discussing in this WG. > > What am I expecting to get if I plug in urn:service:sos.fire into my > URN resolver? Should it be a URLs pointing to a web page about the > "sos.fire" identifier? Or is it URLs to all the mapping services of > the world that service "sos.fire"? There are several possible models, depending on the number of such mapping protocols. There are several cases, depending on whether one can rely on the fact that all services for a particular URN are available in all mapping protocols (this might be a condition for registration) or not. If they are, a client can simply choose whatever protocol it supports. If not, things get messier. My preference would be a very small number of such protocols, just as most other URN schemes have somewhere close to one resolution mechanisms (well, zero in some cases). I didn't want to specify this right now, as that gets into tangential arguments, which also depend on the resolution of the mapping protocol discussion within ECRIT. > > Is this approach meant to make countries with unique emergency > identifiers register those identifiers in a global registry? If not, > then are you expecting "adhoc URNs" in the service NID? I'm not sure what you mean by "unique emergency identifiers". Are you talking about dial strings like 911 or, say, a new type of emergency, such as my Italian sos.fashion example? For the latter, I would indeed expect them to register such services, in the same fashion that they would register such service identifiers in your mapping proposal. > > I know you put TBD for the namespace registrant, but who did you have > in mind that would run this NID? Is it the ITU? And what rules are > they willing to use to insure that identifiers with duplicate meaning > are not registered? Such as a particularly stubborn government wishing > to register their national languages equivalent to "police". The rules would be similar to the rules that would need to be imposed for service identifiers that appear "naked" in the ECRIT mapping protocol. The usual set of IANA policies, from FCFS to standards document, may apply. Thanks for your questions; they help to flesh out the proposal. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 12 22:52:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsXMH-0000We-H7; Tue, 12 Jul 2005 22:52:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsXMG-0000WZ-Fh for ecrit@megatron.ietf.org; Tue, 12 Jul 2005 22:52: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 WAA19058 for ; Tue, 12 Jul 2005 22:52:22 -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 1DsXoa-0001fz-LP for ecrit@ietf.org; Tue, 12 Jul 2005 23:21:41 -0400 Received: from [192.168.0.31] (pool-141-153-198-113.mad.east.verizon.net [141.153.198.113]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j6D2qJNs024122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Jul 2005 22:52:20 -0400 (EDT) Message-ID: <42D481AC.7060208@cs.columbia.edu> Date: Tue, 12 Jul 2005 22:51:24 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Hardie Subject: Re: [Ecrit] deployment (was R:5) 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: 202a3ece0492a8c7e7c8672d5214398f 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 Ted Hardie wrote: > services provider. Instead, I believe, the proxy server will talk > either to a mapping server maintained by its own organization or to > the servers of the organization that is the source of the mapping > data. I would add that the corporate outbound proxy could also be talking to the mapping service maintained by another vendor, such as a voice service provider offering enterprise-level services, that is itself not the (authoritative) source of the mapping data. If we assume a model where authoritative data is distributed, it is unlikely that that proxy server will directly talk to such a server - simply because it has no clue who that server might be. I'm probably missing what you mean by "source", but assume for a moment that mapping data is maintained by each country, just to keep the number of layers down. If a proxy needs to find out who provides rescue services for 123 Main Street, Ottawa, Canada, the client doesn't know the "source" of that data (the Canadian authority). It somehow needs to find that first-contact server that knows who handles Canada. One model is the DNS "root" model - start at the well-known (logical) top and traverse the tree. > > So here's my assumption one: the source of the mapping data runs one > or more mapping servers, and these are available for querying. This > is necessary for cache-fill replication, and it makes sense for local > mapping servers that have to mix data from multiple sources. It also > provides a "default" server to query when a local mapping server > isn't available (either because it isn't provided or beause it's down > during the emergency). It isn't strictly necessary from a protocol > standpoint, since other servers can serve replicated data derived > from other replication mechanisms, but I think we should optimize for > the case where this is true. My problem here is that there is no single source of mapping data, unless you consider a model where an organization, through some unspecified means, aggregates information for the whole world and makes it appear that it knows mappings for every street and location in the world. > In the proxy server case, a voice service provider's mapping server > will likely need to mix data derived from multiple mapping sources. > This will be true whenever the organization's service boundaries > cross those of mapping sources (certainly true for multi-national and > multi-State U.S. service providers, and likely true at even smaller > units). Note that there is no protocol requirement that it get that > data using the same query protocol used by the caller; it's very > likely to be more efficient to get it by other means, either in an > extension to the protocol or through some other data transfer > protocol. Put another way, data replication is a systemic > requirement, not a requirement for the query protocol itself. I suppose one could design DNS so that the client-resolver query protocol differs from the server-server protocol. As far as I can tell, the requirements for the two are close enough that I see no advantage, but lots of structural disadvantages, of doing so. > > For the case in which the mapping step occurs prior to the call flow > being initiated, the caller may contact a mapping server associated > with the voice services provider, one associated with the source of > the mapping data, one associated with an access provider, or one > associated with some other party (in some countries, for example, the > government may run local mapping servers on behalf of the public > good). The caller can, of course, only contact a mapping server that > it knows about and is reachable. The problem is that each such mapping server would have to know the whole world, thus essentially becoming a giant cache. > > Here's my assumption two: callers will have multiple ways to derive > knowledge about available mapping servers. They may have one > configured by their voice services provider. They may learn one via > DHCP from an access provider. They may be able to locate the mapping > server from something like slp if they are querying in advance of > need. As part of this assumption, I assume that any mapping server > they reach can provide a referral to the correct server to query if > it does not have the data locally; alternatively, it may query on > behalf of the client and return the data. I think we agree on that assumption. There clearly should be multiple entry-ways into the maze of mapping servers. > I also believe we're talking about data where freshness is measured > in large numbers of minutes. I believe if we go down to seconds > (even in large numbers), we run the risk of the call not completing > before the information is stale; that's bad. If we measure in Agreed. As far as I can tell, load balancing between different PSAPs should be done at a different layer, such as the DNS lookup that occurs when the mapping protocol returns. There are well-known techniques, already specified in likely signaling protocols, that offer this capability. > minutes we can handle the common case (reasonably long-lived), but > also handle the case where it needs to be shortened in order to > handle a transition. In the DNS, for example, the common case is > TTLs on the order of three days, but these are shortened prior to > changes to short times (e.g. 15 minutes), so that the extant data > ages out of cacches and is refreshed with long-lived data once the > transition occurs. A mechanism to allow pre-fetch of data before it > is "live" is even better here, since it replicates the data without > waiting until it is known stale. This reinforces the point that the > mechanism to query for current state and the mechanism for keep > server replicas up to date do not need to be the same, since this is > protocol element not interesting to the caller's mapping query > interface. I suspect you could design a different protocol, but I have a hard time seeing how this would allow us to build thousands, if not millions, of per-client-organization mapping servers, as you posit earlier. In other words, we would not be solving the real problem of having a deployable system without immediately turning around and designing that other protocol. > > I realize that many elements of this data do not change over very > long periods (years, as I understand it, for one common case), but I > don't believe that means we should measure in days or weeks. If > reasonably possible, we need to get fresh data to the user and or > server of replicated date. That means taking a minor hit on network > traffic to increase the possibility the data is good; it's a tradeoff > but I think its the right one. My perception is that the main changes are due to two factors: new subdivisions get build (frequent in some parts of the US, impossible in the town I live in), adding new entries, or service boundaries change (appears to be rare and is probably something where both old and new will work for a while). In any event, as long as we agree on the rough timescale, a factor of ten up isn't going to make much difference. Adding new entries obviously does not impact cache freshness, just hit ratios. There may well be a trade-off which is a bit different from other lookup applications, namely timeliness: If I have a result cached and can't get the new result within (say) a second, I'm probably better off routing to the old result rather than waiting. Total response time, from dialing to pickup by a human, has an SLA of less than ten seconds, after all, and you don't want to "burn" eight of those confirming, with 99% probability, the result you already had eight seconds earlier. > > On another "taking a hit" front, I think we have to rule out any > requirement that the system provide a mechanism for winnowing data > sets; if a replicated server has to have full data sets available in > order to provide the data it needs, it may need to take the hit in > terms of data storage and indexing. The number of potential database > views is, after all, practically infinite, and burdening the > authoritative source with the ability to generate them is onerous > whatever the transfer mechanism may be. A replica of an authoritative source definitely needs to have the full set for the region that it is authoritative for (not the whole world) - otherwise it isn't a replica. However, local non-authoritative copies don't need anything close to the full set to be useful in reducing the average response time under both routine and adverse network conditions. > > There are clearly other assumptions we could tease apart here, but I > thought I'd start from these and get others' reactions. regards, Ted > Hardie > > _______________________________________________ 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 Jul 12 23:17:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsXkK-0007Pa-JX; Tue, 12 Jul 2005 23:17:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsXkI-0007PP-BM for ecrit@megatron.ietf.org; Tue, 12 Jul 2005 23:17: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 XAA20617 for ; Tue, 12 Jul 2005 23:17:12 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsYCb-0002OI-ID for ecrit@ietf.org; Tue, 12 Jul 2005 23:46:30 -0400 Received: from [10.0.1.2] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Tue, 12 Jul 2005 23:17:04 -0400 id 00117D0E.42D487B0.00006DE0 In-Reply-To: <42D473C4.4090400@cs.columbia.edu> References: <42C5F37D.4000304@cs.columbia.edu> <42CFE21F.9060605@cs.columbia.edu> <42D323E6.1000909@cs.columbia.edu> <4E051C1C-8440-4B12-AFA0-ABC6AF7A6536@hxr.us> <42D32820.8080203@cs.columbia.edu> <42D3323C.2060107@cs.columbia.edu> <242B5B7E-94E0-4B44-9A0F-02BAA9909DD7@hxr.us> <42D473C4.4090400@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <509AB63A-A265-4737-A204-4783739CE221@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] simplified R5? Date: Tue, 12 Jul 2005 23:16:59 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Jul 12, 2005, at 9:52 PM, Henning Schulzrinne wrote: > I have no objection to you believing your particular network > architecture does not need replication (or caching) Henning, You have misunderstood what I have stated. It isn't that I do not see a need for database replication. It is that I do not see a need for database replication in the protocol spoken by a client attempting to do location-to-URI mapping. Additionally, it would appear that you do believe there will be a need for database replication. That is fine. And that is what your requirement should speak of, but it does not. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 13 15:38:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsn4K-00055e-U0; Wed, 13 Jul 2005 15:38:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsn4G-00053V-Rk for ecrit@megatron.ietf.org; Wed, 13 Jul 2005 15:38: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 PAA14857 for ; Wed, 13 Jul 2005 15:38:51 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsnWj-0008WG-FJ for ecrit@ietf.org; Wed, 13 Jul 2005 16:08:18 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6DJcLWQ020695; Wed, 13 Jul 2005 12:38:21 -0700 (PDT) Received: from [192.168.1.4] (carbuncle.qualcomm.com [129.46.227.161]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6DJcITT007453; Wed, 13 Jul 2005 12:38:19 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <42D481AC.7060208@cs.columbia.edu> References: <42D481AC.7060208@cs.columbia.edu> Date: Wed, 13 Jul 2005 12:38:16 -0700 To: Henning Schulzrinne From: Ted Hardie Subject: Re: [Ecrit] deployment (was R:5) Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 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 At 10:51 PM -0400 7/12/05, Henning Schulzrinne wrote: >Ted Hardie wrote: > >>services provider. Instead, I believe, the proxy server will talk >>either to a mapping server maintained by its own organization or to >>the servers of the organization that is the source of the mapping >>data. > >I would add that the corporate outbound proxy could also be talking to the mapping service maintained by another vendor, such as a voice service provider offering enterprise-level services, that is itself not the (authoritative) source of the mapping data. It makes sense that people might outsource this, but I want to clarify if you that service will be delivered with a box on the corporate network or not. That is, does Example corp contract with Invalid VSP for service and get a local copy of the needed mapping service fed by some form of data replication by Invalid VSP? or does Example corp just point its proxies to Invalid's mapping servers? I think the "deployment advice" document wordage I've been suggesting go with this might want to recommend something here.... >If we assume a model where authoritative data is distributed, it is unlikely that that proxy server will directly talk to such a server - simply because it has no clue who that server might be. To clarify, distributed by locality, right? Some agency in Campbell, Santa Clara County, the state of California or the U.S is authoritative for where I sit in Campbell, CA and a different one is authoritative when I'm in New Orleans, LA at my brother's house. (We're not talking about, it other words, one source being authoritative for one *kind* of data and one for another") >I'm probably missing what you mean by "source", but assume for a moment that mapping data is maintained by each country, just to keep the number of layers down. If a proxy needs to find out who provides rescue services for 123 Main Street, Ottawa, Canada, the client doesn't know the "source" of that data (the Canadian authority). It somehow needs to find that first-contact server that knows who handles Canada. One model is the DNS "root" model - start at the well-known (logical) top and traverse the tree. > I've been thinking of it in registry terms. There is a registry of mappings for a specific locality that is authoritative for that locality. That registry serves data on its information by those making queries to it or by data replication to other servers interested in serving queries for its locality. The mapping servers which are not registries have data derived from one or more registries and make it available using the same query protocol. Either the registry or a non-registry mapping server may provide a referral to another registry if it does not have appropriate data; it may do that by pointing to the top of a hierarchy or by more direct referral (the latter would be more efficient, if it maintains mappings below the top). > >> >>So here's my assumption one: the source of the mapping data runs one >>or more mapping servers, and these are available for querying. This >>is necessary for cache-fill replication, and it makes sense for local >>mapping servers that have to mix data from multiple sources. It also >>provides a "default" server to query when a local mapping server >>isn't available (either because it isn't provided or beause it's down >>during the emergency). It isn't strictly necessary from a protocol >>standpoint, since other servers can serve replicated data derived >>from other replication mechanisms, but I think we should optimize for >>the case where this is true. > >My problem here is that there is no single source of mapping data, unless you consider a model where an organization, through some unspecified means, aggregates information for the whole world and makes it appear that it knows mappings for every street and location in the world. I didn't mean "the source of all mapping data", I meant the "source of mapping data for a specific area". Sorry that that was not clear. Aggregating all known information should not be required for correct operation of the protocol, even if there were a tree-walk way to accomplish it. >>In the proxy server case, a voice service provider's mapping server >>will likely need to mix data derived from multiple mapping sources. >>This will be true whenever the organization's service boundaries >>cross those of mapping sources (certainly true for multi-national and >>multi-State U.S. service providers, and likely true at even smaller >>units). Note that there is no protocol requirement that it get that >>data using the same query protocol used by the caller; it's very >>likely to be more efficient to get it by other means, either in an >>extension to the protocol or through some other data transfer >>protocol. Put another way, data replication is a systemic >>requirement, not a requirement for the query protocol itself. > >I suppose one could design DNS so that the client-resolver query protocol differs from the server-server protocol. As far as I can tell, the requirements for the two are close enough that I see no advantage, but lots of structural disadvantages, of doing so. > Di you mean "DNS" above, of the mapping protocol? DNS does have a different query protocol from a server to server protocol; the server to server protocol (AXFR) is designed to retrieve zonefuls of data, rather than using an opportunistic cache fill. A caching resolver can, of course, also use a standard query to fill its cache. But it's interesting to look at the motivation for the two transfer mechanisms. Using AXFR is a good way to get closely related information (the data in a single zone/level of the DNS hierarchy); opportunistic cache fill based on demand is a good way to get data based on usage patterns when those patterns don't relate to a single zone. Since you want the mapping servers in different parts of the network topology to be able to serve all of the data associated with the localities which they serve, I think the zone transfer model (or full replication model, in non-DNS terms) makes more sense. Even if a mapping server handles data from multiple registries, it can likely handle the full data transfer pretty easily. > >> >>For the case in which the mapping step occurs prior to the call flow >>being initiated, the caller may contact a mapping server associated >>with the voice services provider, one associated with the source of >>the mapping data, one associated with an access provider, or one >>associated with some other party (in some countries, for example, the >>government may run local mapping servers on behalf of the public >>good). The caller can, of course, only contact a mapping server that >>it knows about and is reachable. > >The problem is that each such mapping server would have to know the whole world, thus essentially becoming a giant cache. > See above clarification. >> >>Here's my assumption two: callers will have multiple ways to derive >> knowledge about available mapping servers. They may have one configured by their voice services provider. They may learn one via >>DHCP from an access provider. They may be able to locate the mapping >>server from something like slp if they are querying in advance of >>need. As part of this assumption, I assume that any mapping server they reach can provide a referral to the correct server to query if >>it does not have the data locally; alternatively, it may query on >>behalf of the client and return the data. > >I think we agree on that assumption. There clearly should be multiple entry-ways into the maze of mapping servers. > >>I also believe we're talking about data where freshness is measured >>in large numbers of minutes. I believe if we go down to seconds >>(even in large numbers), we run the risk of the call not completing >>before the information is stale; that's bad. If we measure in > >Agreed. As far as I can tell, load balancing between different PSAPs should be done at a different layer, such as the DNS lookup that occurs when the mapping protocol returns. There are well-known techniques, already specified in likely signaling protocols, that offer this capability. > >>minutes we can handle the common case (reasonably long-lived), but >>also handle the case where it needs to be shortened in order to >>handle a transition. In the DNS, for example, the common case is >>TTLs on the order of three days, but these are shortened prior to >>changes to short times (e.g. 15 minutes), so that the extant data ages out of cacches and is refreshed with long-lived data once the >>transition occurs. A mechanism to allow pre-fetch of data before it >>is "live" is even better here, since it replicates the data without >>waiting until it is known stale. This reinforces the point that the >>mechanism to query for current state and the mechanism for keep >>server replicas up to date do not need to be the same, since this is >>protocol element not interesting to the caller's mapping query >>interface. > >I suspect you could design a different protocol, but I have a hard time seeing how this would allow us to build thousands, if not millions, of per-client-organization mapping servers, as you posit earlier. In other words, we would not be solving the real problem of having a deployable system without immediately turning around and designing that other protocol. Perhaps other protocol is too strong and "other mechanism" would be better, but the point is that you don't have to use many, many individual queries to get the data; you can use a more tailored mechanism for cases where you want replication of all of locality's data. > > >> >>I realize that many elements of this data do not change over very >>long periods (years, as I understand it, for one common case), but I >>don't believe that means we should measure in days or weeks. If >>reasonably possible, we need to get fresh data to the user and or >>server of replicated date. That means taking a minor hit on network >>traffic to increase the possibility the data is good; it's a tradeoff >> but I think its the right one. > >My perception is that the main changes are due to two factors: new subdivisions get build (frequent in some parts of the US, impossible in the town I live in), adding new entries, or service boundaries change (appears to be rare and is probably something where both old and new will work for a while). In any event, as long as we agree on the rough timescale, a factor of ten up isn't going to make much difference. > >Adding new entries obviously does not impact cache freshness, just hit ratios. > >There may well be a trade-off which is a bit different from other lookup applications, namely timeliness: If I have a result cached and can't get the new result within (say) a second, I'm probably better off routing to the old result rather than waiting. Total response time, from dialing to pickup by a human, has an SLA of less than ten seconds, after all, and you don't want to "burn" eight of those confirming, with 99% probability, the result you already had eight seconds earlier. I agree that if you have some result, routing to it as soon as possible makes sense. That was why I orginally stated that we were designing for the case where there was no data available to the caller. > >> >>On another "taking a hit" front, I think we have to rule out any >>requirement that the system provide a mechanism for winnowing data >>sets; if a replicated server has to have full data sets available in >>order to provide the data it needs, it may need to take the hit in >>terms of data storage and indexing. The number of potential database >>views is, after all, practically infinite, and burdening the >>authoritative source with the ability to generate them is onerous whatever the transfer mechanism may be. > >A replica of an authoritative source definitely needs to have the full set for the region that it is authoritative for (not the whole world) - otherwise it isn't a replica. However, local non-authoritative copies don't need anything close to the full set to be useful in reducing the average response time under both routine and adverse network conditions. > I think this goes back to the global set misunderstanding before, but just in case, let me elaborate. You mentioned the case of a company with 20 franchises. Let's assume that company wants to maintain a mapping server that covers the locations of those 20 franchises as part of its VoIP infrastructure. Those 20 franchises are in 3 towns and two states, and there are a total of 3 registries which have the authoritative mapping data covering the areas of the franchises. I'm saying that it we should not make a systemic requirement that the company's mapping server get custom data replication service from the authoritative registries. If it gets the data via data replication, it may well get data it doesn't need, but that's the right trade off (versus having the responsible registries generate a custom view (in database terms) for the query). thanks for your response, Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 13 16:26:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsnoi-0006ZP-LU; Wed, 13 Jul 2005 16:26:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsnoh-0006Yx-5o for ecrit@megatron.ietf.org; Wed, 13 Jul 2005 16:26: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 QAA29947 for ; Wed, 13 Jul 2005 16:26:49 -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 1DsoH7-0005ro-3I for ecrit@ietf.org; Wed, 13 Jul 2005 16:56:16 -0400 Received: from [160.39.251.86] (dyn-160-39-251-86.dyn.columbia.edu [160.39.251.86]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j6DKQe92014028 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 13 Jul 2005 16:26:40 -0400 (EDT) In-Reply-To: References: <42D481AC.7060208@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <786E0C7A-B162-4EAD-824C-3D440FFFFBE7@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] deployment (was R:5) Date: Wed, 13 Jul 2005 16:26:38 -0400 To: Ted Hardie X-Mailer: Apple Mail (2.733) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 1.3 (+) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 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 this discussion would benefit from a whiteboard or at least some slide diagrams, as I have the nagging suspicion that terminology and assumption either hide or amplify disagreements. There are only a relatively small number of tools in our big-picture design toolbox for distributed directory/mapping/lookup protocols, after all. [snipping a lot] On Jul 13, 2005, at 3:38 PM, Ted Hardie wrote: > > It makes sense that people might outsource this, but I want to > clarify if > you that service will be delivered with a box on the corporate > network or > not. That is, does Example corp contract with Invalid VSP for > service and > get a local copy of the needed mapping service fed by some form of > data replication by Invalid VSP? or does Example corp just point > its proxies > to Invalid's mapping servers? > Several options: Example corp could have its own mapping server and gets some subset of the data (where subset obviously includes "the whole world" as one option), either as-needed or ahead of time, i.e., either push or pull. To avoid misunderstandings: as-needed does not necessarily imply "when the user dials 9-1-1", but could be "when the user gets a new address/location and needs to verify that this is valid". Clearly, pointing at the VSP is another option. > I think the "deployment advice" document wordage I've been > suggesting go > with this might want to recommend something here.... > I think it will be hard to recommend any specific solution - this will be driven by costs and other considerations. (If Example Corp pays per lookup, it might want to keep data locally to avoid paying for each validation, for example.) I don't think it is particularly hard to support both push and pull models; as a community, we've done this type of stuff for 20+ years, on 8-bit hardware. > > >> If we assume a model where authoritative data is distributed, it >> is unlikely that that proxy server will directly talk to such a >> server - simply because it has no clue who that server might be. >> > > To clarify, distributed by locality, right? Some agency in > Campbell, Santa Clara County, > the state of California or the U.S is authoritative for where I sit > in Campbell, CA and > a different one is authoritative when I'm in New Orleans, LA at my > brother's house. Yes, distributed by locality. > > (We're not talking about, it other words, one source being > authoritative for one *kind* > of data and one for another") Not sure what you mean by "kind of data", but it is perfectly possible, as has been discussed here, that there's one hierarchy for marine rescue (probably not much coverage for the Alps) and another one for mountain rescue (may not be populated in Holland), managed by different (government) entities in terms of mapping data. > > I've been thinking of it in registry terms. There is a registry of > mappings for a > specific locality that is authoritative for that locality. That > registry serves > data on its information by those making queries to it or by data > replication > to other servers interested in serving queries for its locality. > The mapping > servers which are not registries have data derived from one or more > registries > and make it available using the same query protocol. Either the > registry or > a non-registry mapping server may provide a referral to another > registry > if it does not have appropriate data; it may do that by pointing to > the > top of a hierarchy or by more direct referral (the latter would be > more > efficient, if it maintains mappings below the top). > > That sounds close to my mental model, but we probably need to start working on a common terminology to avoid needlessly wasting time on non-existing disagreements. I'm trying to minimize the number of entities involved and unify them as much as possible, just to keep the interface count down. In my view, we have two kinds of entities: - Authoritative: They contain a known-correct set of mappings directly managed by the data owner, but this set of mappings may not actually point to an emergency URI, but rather to another mapping server. The set of such servers can be large (e.g., one per PSAP in the US). For example, if there's a US server, it might have 51 entries (both in civic and as polygons) outlining the states and DC, each with a references such as "ecrit:someserver.ca" (for CA). This leads to the standard referral model. Alternatively, in the recursion model, the US server will make the query itself, returning an emergency URI to the querier. (The querier could obviously be another ECRIT server, e.g., the one operated by the United Nations for the whole world, if that's how the system ends up being built.) - Non-authoritative: The server contains bindings (polygons, civic tuples) that it has learned from somewhere else, to speed up requests and to avoid that every request has to go to the "world root" and down again. The set of such servers can be very large - e.g., every enterprise could have one. Learning can happen by push or pull, i.e., explicitly by getting the data from somewhere or by doing recursive queries and keeping the result for future use. Again, this is not exactly new - LDAP, DNS and other directory-like systems all work pretty much like that. (Even SIP shares some aspect of this model, as it is partially a binding management protocol.) As a first contact, a client needs to find a server that has bindings for the area it cares about. There is only a finite number of ways that I have seen that this can be done, essentially boiling down to "tall tree" and "forest" models. Again, a picture would help here. > > I didn't mean "the source of all mapping data", I meant the "source > of mapping > data for a specific area". Sorry that that was not clear. > Aggregating all known > information should not be required for correct operation of the > protocol, even > if there were a tree-walk way to accomplish it. > Glad we agree on that. I think we kind of have this in the requirements list, but this needs to be captured very clearly. I suspect that there are a number of people, particularly outside ECRIT, who will hear directory and think "BigEvilEntity-run white pages listing each PSAP in the world" (and hear the black helicopters buzzing in the background if BigEvilEntity = UN.) > > Di you mean "DNS" above, of the mapping protocol? DNS does have a > different > query protocol from a server to server protocol; the server to > server protocol > (AXFR) is designed to retrieve zonefuls of data, rather than using > an opportunistic > cache fill. A caching resolver can, of course, also use a standard > query to fill > its cache. But it's interesting to look at the motivation for the > two transfer > mechanisms. Using AXFR is a good way to get closely related > information (the > data in a single zone/level of the DNS hierarchy); opportunistic > cache fill > based on demand is a good way to get data based on usage patterns when > those patterns don't relate to a single zone. Since you want the > mapping > servers in different parts of the network topology to be able to > serve all of > the data associated with the localities which they serve, I think > the zone > transfer model (or full replication model, in non-DNS terms) makes > more sense. > Even if a mapping server handles data from multiple registries, it > can likely > handle the full data transfer pretty easily. > See above. I think we need both models for scaling and avoiding the "go to root for each query" problem. I agree with you that these have different applications (full vs. partial/opportunistic replication). > > Perhaps other protocol is too strong and "other mechanism" would be > better, > but the point is that you don't have to use many, many individual > queries > to get the data; you can use a more tailored mechanism for cases where > you want replication of all of locality's data. > I agree that just using a bunch of queries for replication is not likely to be efficient or appropriate, so it will at least be a different protocol operation. > > I agree that if you have some result, routing to it as soon as > possible makes sense. > That was why I orginally stated that we were designing for the case > where there > was no data available to the caller. > Maybe there's another requirement lurking here, as this differs from standard mapping/lookup protocols: "If caching is used, servers should return these cached results if they cannot obtain a current mapping in a timely fashion." If you can design a protocol without caching, this requirement obviously wouldn't apply to you, but then we might need to agree on something like "It should be avoided that each query has to visit the same set of global "root" servers." Motivation: reliability, single (logical) point of failure and juicy target for evildoers. > > I think this goes back to the global set misunderstanding before, > but just in > case, let me elaborate. You mentioned the case of a company with > 20 franchises. > Let's assume that company wants to maintain a mapping server that > covers > the locations of those 20 franchises as part of its VoIP > infrastructure. Those > 20 franchises are in 3 towns and two states, and there are a total > of 3 registries > which have the authoritative mapping data covering the areas of the > franchises. > I'm saying that it we should not make a systemic requirement that the > company's mapping server get custom data replication service from > the authoritative > registries. If it gets the data via data replication, it may well > get data > it doesn't need, but that's the right trade off (versus having the > responsible > registries generate a custom view (in database terms) for the query). > These servers can either get copies of the whole listing (as you suggest) or can learn the necessary mappings. The latter might work better for widely-distributed organizations. (For example, I believe JetBlue has its reservation agents work from home, anywhere in the US and, who knows, in India.) Learning the mappings ahead of time isn't hard - the requirement for validation means that any VoIP client (or their proxy stand-in) with a new address will have to make a pre-need call to ECRIT in any event. > thanks for your response, > Ted > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 13 16:47:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dso8H-0003rl-9H; Wed, 13 Jul 2005 16:47:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dso8E-0003q7-IK for ecrit@megatron.ietf.org; Wed, 13 Jul 2005 16:47: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 QAA09483 for ; Wed, 13 Jul 2005 16:47:00 -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 1Dsoah-0000pE-3p for ecrit@ietf.org; Wed, 13 Jul 2005 17:16:28 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 13 Jul 2005 13:46:52 -0700 X-IronPort-AV: i="3.93,287,1115017200"; d="scan'208"; a="304713309:sNHT49068106" 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 j6DKkloj003635 for ; Wed, 13 Jul 2005 13:46:48 -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); Wed, 13 Jul 2005 13:46:46 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Jul 2005 13:46:46 -0700 From: "Marc Linsner" To: Date: Wed, 13 Jul 2005 16:46:47 -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: AcWH6/ucxqXdu6fBT9q4w4kT+q6JnQ== Message-ID: X-OriginalArrivalTime: 13 Jul 2005 20:46:46.0728 (UTC) FILETIME=[FC251480:01C587EB] X-Spam-Score: 1.1 (+) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit Subject: [Ecrit] Agenda time in Paris 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 If you want to present in Paris, let us know. Thanks, Marc & Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jul 16 14:17:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtrEb-00074h-FI; Sat, 16 Jul 2005 14:17:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtrEZ-00074S-Qf for ecrit@megatron.ietf.org; Sat, 16 Jul 2005 14:17: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 OAA20474 for ; Sat, 16 Jul 2005 14:17:53 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dtoa8-0003dU-Dp for ecrit@ietf.org; Sat, 16 Jul 2005 11:28:03 -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 ; Sat, 16 Jul 2005 10:57: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] WG: updated I-D: draft-schulzrinne-ecrit-requirements-01.txt Date: Sat, 16 Jul 2005 07:57:35 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657502B2E16E@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] WG: updated I-D: draft-schulzrinne-ecrit-requirements-01.txt Thread-Index: AcVSfG5supQyJEqRSZGS41N9yJhQXwIyqlzgAB61AZAISQhYEAABAifwAbh79sABklmcgA== From: "Roger Marshall" To: , "Tschofenig Hannes" , "Marc Linsner" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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: An updated version of the ecrit requirements draft has been posted, and can be accessed via the following link: http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-requirements -01.txt There remain some of the original requirements, such as A1, A3, and R5, which have not been resolved to an agreed on state. =20 The original numbering of requirements have been retained (per -00) to provide context. Comments are encouraged. -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 Tue Jul 19 10:51:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DutRv-0000k5-KY; Tue, 19 Jul 2005 10:51:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DutRu-0000k0-1G for ecrit@megatron.ietf.org; Tue, 19 Jul 2005 10:51: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 KAA20275 for ; Tue, 19 Jul 2005 10:51:55 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DutvU-00022x-Up for ecrit@ietf.org; Tue, 19 Jul 2005 11:22:36 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j6JEpeQ4015853 for ; Tue, 19 Jul 2005 16:51:40 +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 j6JEpdqK012973 for ; Tue, 19 Jul 2005 16:51:40 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.146]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 19 Jul 2005 16:51:39 +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, 19 Jul 2005 16:51:38 +0200 Message-ID: Thread-Topic: ecrit security draft Thread-Index: AcWMcVqki74+SYd4TYSOrwRxKU1xHw== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 19 Jul 2005 14:51:39.0549 (UTC) FILETIME=[5E8E14D0:01C58C71] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] ecrit security draft 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 at the interim meeting several persons volunteered to work on the security draft.=20 my hope was that someone (not me) pushes this document forward. i was wrong.=20 on monday i submitted an update of the draft.=20 you can find it at:=20 http://www.tschofenig.priv.at/drafts/draft-tschofenig-ecrit-security-threats -01.txt http://www.tschofenig.priv.at/drafts/draft-tschofenig-ecrit-security-threats -01.html please let me know if you are interested to work on this document.=20 ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 19 15:20:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duxe7-0000yS-Cf; Tue, 19 Jul 2005 15:20:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duxe5-0000yN-JK for ecrit@megatron.ietf.org; Tue, 19 Jul 2005 15:20: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 PAA25028 for ; Tue, 19 Jul 2005 15:20:47 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Duy7k-0000Cw-4k for ecrit@ietf.org; Tue, 19 Jul 2005 15:51:30 -0400 Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Tue, 19 Jul 2005 15:20:43 -0400 id 0022B143.42DD528B.0000331A Mime-Version: 1.0 (Apple Message framework v730) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <48583107-F651-4976-8CEF-29195CD688AB@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Date: Tue, 19 Jul 2005 15:20:41 -0400 To: ecrit@ietf.org X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Subject: [Ecrit] Fwd: I-D ACTION:draft-hardie-ecrit-iris-02.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 Ted, Hannes, and I have put out a new version of the ECON draft. Here is a brief list of the things that have changed: 1) We added some more descriptive text on the usage of the protocol. 2) In an attempt to think outside the box, we have changed the service type from a single list of identifiers and instead have broken it out into function (police, fire, ...), area (marine, urban,...), and target (child, adult, ...). 3) A query has been added to discover local emergency services (based on Richard's comments). 4) The ECON results now have a TTL so that clients (devices needing the service, not intermediaries) can be kept from hammering the service. 5) There is a section on database replication including a mechanism to replicate changes out to local copies before the data becomes effective. And I'm sure there is something else I missed. Anyway, comments are welcome. -andy Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: July 15, 2005 3:50:01 PM EDT > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-hardie-ecrit-iris-02.txt > Reply-To: internet-drafts@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : An IRIS schema for Emergency Service contact URIs > Author(s) : T. Hardie, et al. > Filename : draft-hardie-ecrit-iris-02.txt > Pages : 32 > Date : 2005-7-15 > > This document describes an XML-based protocol for passing location > information to a server that returns emergency service contact > URIs. > It is intended to fit within a larger framework of standards. > Specifically, it presumes the existence of a URI scheme appropriate > for signalling that emergency service is required and > distinguishing > among emergency services if appropriate. It also presumes that an > entity requesting this response will be able to handle the URIs > returned as input to appropriate handlers. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-hardie-ecrit-iris-02.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-hardie-ecrit-iris-02.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-hardie-ecrit-iris-02.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. > Content-Type: text/plain > Content-ID: <2005-7-15115817.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 19 18:18:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv0Q9-0002ml-FW; Tue, 19 Jul 2005 18:18:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv0Q8-0002mb-AV for ecrit@megatron.ietf.org; Tue, 19 Jul 2005 18:18: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 SAA03943 for ; Tue, 19 Jul 2005 18:18:33 -0400 (EDT) Message-Id: <200507192218.SAA03943@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dv0tp-0000j2-Ih for ecrit@ietf.org; Tue, 19 Jul 2005 18:49:18 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41xp) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1Dv0Pu-00017O-Kn for ecrit@ietf.org; Tue, 19 Jul 2005 17:18:23 -0500 From: "Brian Rosen" To: "'ECRIT'" Date: Tue, 19 Jul 2005 18:18:19 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_04CF_01C58C8E.3FD51120" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWMohcYjkmWAhVJTlmirWyCc6wDnwADYWIg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 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: b132cb3ed2d4be2017585bf6859e1ede Subject: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.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_000_04CF_01C58C8E.3FD51120 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have refreshed this. No significant changes; just some language tightening. Brian -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, July 19, 2005 3:50 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-rosen-dns-sos-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Emergency Call Information in the Domain Name System Author(s) : B. Rosen Filename : draft-rosen-dns-sos-02.txt Pages : 20 Date : 2005-7-19 Location of a caller is essential to processing an emergency call. Location is needed to correctly route the call, and to correctly dispatch help to the right place. Location can be specified in geographic (latitude, longitude) or civic (country, province, locality) forms. This document proposes a DNS-based mechanism to lookup emergency calling URIs and related emergency information from a known civic location in a specific form. Other companion documents propose a non DNS-based approach to determine civic location from geographic location, and describe how to discover a civic location in the appropriate local form(s) for this application. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosen-dns-sos-02.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-rosen-dns-sos-02.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-rosen-dns-sos-02.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_000_04CF_01C58C8E.3FD51120 Content-Type: Message/External-body; name="ATT00697.dat" Content-Disposition: attachment; filename="ATT00697.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-7-19113911.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosen-dns-sos-02.txt ------=_NextPart_000_04CF_01C58C8E.3FD51120 Content-Type: Message/External-body; name="draft-rosen-dns-sos-02.txt" Content-Disposition: attachment; filename="draft-rosen-dns-sos-02.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-7-19113911.I-D@ietf.org> ------=_NextPart_000_04CF_01C58C8E.3FD51120 Content-Type: text/plain; name="ATT00700.txt" Content-Disposition: attachment; filename="ATT00700.txt" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------=_NextPart_000_04CF_01C58C8E.3FD51120 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_000_04CF_01C58C8E.3FD51120-- From ecrit-bounces@ietf.org Mon Jul 25 16:15:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx9Io-0006pO-A3; Mon, 25 Jul 2005 16:11:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx9Ii-0006oY-1a for ecrit@megatron.ietf.org; Mon, 25 Jul 2005 16:11: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 QAA20505 for ; Mon, 25 Jul 2005 16:11:38 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx9nT-00075z-Ha for ecrit@ietf.org; Mon, 25 Jul 2005 16:43:37 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j6PKAtcM017064; Mon, 25 Jul 2005 22:10:56 +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 j6PKAtkw011272; Mon, 25 Jul 2005 22:10:55 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.146]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 25 Jul 2005 22:10:54 +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: Mon, 25 Jul 2005 22:10:54 +0200 Message-ID: Thread-Topic: ECRIT Agenda Proposal Thread-Index: AcWRUxc22CX5zwQxRyqDXKDnT8sDiwAAJuLw From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 25 Jul 2005 20:10:54.0764 (UTC) FILETIME=[F66E6EC0:01C59154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: schulzrinne@cs.columbia.edu Subject: [Ecrit] WG: ECRIT Agenda 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all,=20 we have just submitted the following ietf#63 ecrit agenda proposal.=20 ciao hannes -----Urspr=FCngliche Nachricht----- Von: Tschofenig, Hannes=20 Gesendet: Montag, 25. Juli 2005 21:58 An: agenda@ietf.org Cc: 'Marc Linsner' Betreff: ECRIT Agenda Proposal Emergency Context Resolution with Internet Technologies WG TUESDAY, August 2, 2005, 1030-1230 Morning Session II =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 10 min o Requirements for Emergency Context Resolution with Internet = Technologies=20 Roger Marshall = http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-requirements-= 01.txt 20 min o Security Threats and Requirements for Emergency Calling Henning Schulzrinne or Hannes Tschofenig=20 = http://www.ietf.org/internet-drafts/draft-tschofenig-ecrit-security-threa= ts-01.txt 15 min o An IRIS schema for Emergency Service contact URIs Andrew Newton or Ted Hardie http://www.ietf.org/internet-drafts/draft-hardie-ecrit-iris-02.txt 20 min o Location-to-URL Mapping Protocol (LUMP) Henning Schulzrinne = http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-lump-00.txt 20 min o Emergency Call Information in the Domain Name System=20 Brian Rosen http://www.ietf.org/internet-drafts/draft-rosen-dns-sos-02.txt 20 min o A Uniform Resource Name (URN) for Services Henning Schulzrinne = http://www.ietf.org/internet-drafts/draft-schulzrinne-sipping-service-00.= txt 15 min _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 29 23:48:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyiKc-0004C4-11; Fri, 29 Jul 2005 23:48:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyiKZ-0004B3-VS for ecrit@megatron.ietf.org; Fri, 29 Jul 2005 23:48: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 XAA27645 for ; Fri, 29 Jul 2005 23:48:08 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyiqN-0001Gb-96 for ecrit@ietf.org; Sat, 30 Jul 2005 00:21:03 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 29 Jul 2005 20:48:11 -0700 Received: from sea-alpha-e2k3.sea-alpha.cisco.com (sea-alpha-e2k3.cisco.com [10.93.132.88]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j6U3lp7B014261 for ; Fri, 29 Jul 2005 20:48:09 -0700 (PDT) Received: from FluffyNotebootk ([171.68.225.134]) by sea-alpha-e2k3.sea-alpha.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Jul 2005 20:52:31 -0700 From: "Cullen Jennings" To: Date: Fri, 29 Jul 2005 23:47:58 -0400 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWUqwBmKnWeuud8TduopM5cq6PF6Q== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-OriginalArrivalTime: 30 Jul 2005 03:52:32.0093 (UTC) FILETIME=[1CFA70D0:01C594BA] X-Spam-Score: 1.1 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Ecrit] schulzrinne-ecrit-lump high level model question 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 seems that you have a whole bunch of hierarchal distributed data and are trying to make a localized query against it. There are two basic approaches, one would be to (as this draft) suggests, distribute the query so it moves through hierarchy and finds the answer. The other approach would be to move the data thought the hierarchy so everyone had a copy of all it and could resolve the query. Some things that might choose between these two approaches are 1) is it too much data to keep a copy of all of it 2) is the data changing too frequently to propagate accurate copies of it 3) how quick to the queries need to be (classic time/space tradeoff) 4) how many nodes have to be "up" and reachable for a query to succeed I guess my question is, are the two approaches I suggest both possible, and if so, which one is the right one for the 911 problem. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 29 23:48:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyiKo-0004De-EL; Fri, 29 Jul 2005 23:48:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyiKm-0004DZ-VP for ecrit@megatron.ietf.org; Fri, 29 Jul 2005 23:48: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 XAA27663 for ; Fri, 29 Jul 2005 23:48:21 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dyiqa-0001HQ-8H for ecrit@ietf.org; Sat, 30 Jul 2005 00:21:16 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 29 Jul 2005 20:48:16 -0700 X-IronPort-AV: i="3.95,154,1120460400"; d="scan'208"; a="201625498:sNHT26657120" Received: from sea-alpha-e2k3.sea-alpha.cisco.com (sea-alpha-e2k3.cisco.com [10.93.132.88]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j6U3lp7H014261 for ; Fri, 29 Jul 2005 20:48:14 -0700 (PDT) Received: from FluffyNotebootk ([171.68.225.134]) by sea-alpha-e2k3.sea-alpha.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Jul 2005 20:52:33 -0700 From: "Cullen Jennings" To: Date: Fri, 29 Jul 2005 23:47:58 -0400 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWUpv3PoES7kTiVSDyLV1k6o+8+mg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-OriginalArrivalTime: 30 Jul 2005 03:52:33.0936 (UTC) FILETIME=[1E13A900:01C594BA] X-Spam-Score: 4.8 (++++) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [Ecrit] tschofenig-ecrit-security-threats 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 In many ways this looks at the VoIP threats in a very well structured approach, but I feel like it is missing some of the obvious overall system problems - problems that are probably not desirable to solve. Let me give a few examples of what I mean .... Section 5.1 - DOS Today, One can DOS a psap by taking a large handful of phones and dialing 911 on them all at the same time. This is because of the limited number of human operators at the PSAP. We don't want to solve this - we don't want to stop more than a handful of phones from calling at once and we don't want to add more operators. One can DOS a police of fire department by phoning in a bomb threat to high school. Folks used to do this at my high school to avoid exams - I hope it is not done so casually today. 5.2 - Call to PSAP with no Identity Do we really want to block 911 calls from pay phones? If caller id does not work for some reason do we want to block the 911 call. I think it is more likely to see that 911 calls will have to work from phones that have not been registered and don't have billing accounts that would even allow a normal call. 5.3 - Location Spoofing No matter how we do location on phones, it will not always work. Today when I phone 911 in the US from a residential PSTN line, the first thing they ask me is where am I. I don't expect this to change. If my phone says I am in San Jose but I tell them I am in Dallas, they transfer to me to Dallas PSAP. I believe that they should continue to rely on the human version of where the human is over the machine version. 5.4 - Impersonating a PSAP It would be an absolute travesty if a given region brought a new PSAP online and then when I called 911, my phone hung up the call because it did not know about the new region. Many, many people are going to end up having access to the credentials that would identify a psap as a real pasp. I could go on with 5.5 to 5.10 but you get the idea. My biggest fear about VoIP 911 is that it will be too complicated and fail when most needed or that it will not be possible to continuously test that it is working. Usually the bad news about security is that it is only as good as the weakest link. I think this is great news for 911, we don't need the security to be stronger than the weakest link. And the weakest link is pretty minimal. Cullen _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jul 30 09:25:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyrLM-0001tf-6n; Sat, 30 Jul 2005 09:25:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyrLL-0001tW-1S for ecrit@megatron.ietf.org; Sat, 30 Jul 2005 09:25: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 JAA09440 for ; Sat, 30 Jul 2005 09:25:33 -0400 (EDT) Message-Id: <200507301325.JAA09440@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyrrD-0002uV-GX for ecrit@ietf.org; Sat, 30 Jul 2005 09:58:31 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41xp) by dx28.winwebhosting.com with esmtpa (Exim 4.51) id 1DyrL4-0003LI-GL; Sat, 30 Jul 2005 08:25:19 -0500 From: "Brian Rosen" To: "'Cullen Jennings'" , Subject: RE: [Ecrit] tschofenig-ecrit-security-threats Date: Sat, 30 Jul 2005 09:25:16 -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: AcWUpv3PoES7kTiVSDyLV1k6o+8+mgAYOFQQ In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.2 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 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 One of the really important messages I ever got was when a PSAP person went on and on and on about how important it was to get validated location, and know who the carrier was, and that the calls were routed to the correct PSAP. I asked him what he wanted to do when all the checks and security and mechanisms still resulted in a call without any of that "Oh, we'll take the call" was the reply. Now, there are rumors of PSAPs not accepting calls under some circumstances, but I have never actually talked to anyone who would admit that they literally would not take a call. So, we need mechanisms, and the mechanisms have to be reliable. However, when the mechanisms fail, you send the call to the best guess PSAP, without the identity, without the security, and they will try to help. That is not any kind of excuse to make mechanisms less rigorous, or implementations sloppy. It's just a "what do you do when despite your best effort it didn't work". You send the call. You never drop an emergency call. You always send it somewhere. PSAPs never (well, okay, there are those rumors) refuse calls. So your conclusion that we don't need much security is incorrect I think. We're working on strategies to deal with DOS on PSAPs. There are around 25,000 call takers on duty at any one time in the U.S. Even if whatever defenses you have for DoS fail, one thing we can do is spread calls out to available call takers and let them sort out the good from the bad. Bad calls get dropped, good calls get forwarded back to the right PSAP. That would have to be done by prior arrangement (the attacked PSAP has to agree to send it's calls elsewhere, other PSAPs have to agree to take them). You would do that in the interval where your firewall failed to detect a new type of attack and when you got a reasonable signature on it to use to filter out the bad calls. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Friday, July 29, 2005 11:48 PM To: ecrit@ietf.org Subject: [Ecrit] tschofenig-ecrit-security-threats In many ways this looks at the VoIP threats in a very well structured approach, but I feel like it is missing some of the obvious overall system problems - problems that are probably not desirable to solve. Let me give a few examples of what I mean .... Section 5.1 - DOS Today, One can DOS a psap by taking a large handful of phones and dialing 911 on them all at the same time. This is because of the limited number of human operators at the PSAP. We don't want to solve this - we don't want to stop more than a handful of phones from calling at once and we don't want to add more operators. One can DOS a police of fire department by phoning in a bomb threat to high school. Folks used to do this at my high school to avoid exams - I hope it is not done so casually today. 5.2 - Call to PSAP with no Identity Do we really want to block 911 calls from pay phones? If caller id does not work for some reason do we want to block the 911 call. I think it is more likely to see that 911 calls will have to work from phones that have not been registered and don't have billing accounts that would even allow a normal call. 5.3 - Location Spoofing No matter how we do location on phones, it will not always work. Today when I phone 911 in the US from a residential PSTN line, the first thing they ask me is where am I. I don't expect this to change. If my phone says I am in San Jose but I tell them I am in Dallas, they transfer to me to Dallas PSAP. I believe that they should continue to rely on the human version of where the human is over the machine version. 5.4 - Impersonating a PSAP It would be an absolute travesty if a given region brought a new PSAP online and then when I called 911, my phone hung up the call because it did not know about the new region. Many, many people are going to end up having access to the credentials that would identify a psap as a real pasp. I could go on with 5.5 to 5.10 but you get the idea. My biggest fear about VoIP 911 is that it will be too complicated and fail when most needed or that it will not be possible to continuously test that it is working. Usually the bad news about security is that it is only as good as the weakest link. I think this is great news for 911, we don't need the security to be stronger than the weakest link. And the weakest link is pretty minimal. Cullen _______________________________________________ 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 Jul 30 09:42:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dyrbp-0004zM-DY; Sat, 30 Jul 2005 09:42:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dyrbn-0004zH-QP for ecrit@megatron.ietf.org; Sat, 30 Jul 2005 09:42: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 JAA10005 for ; Sat, 30 Jul 2005 09:42:34 -0400 (EDT) Message-Id: <200507301342.JAA10005@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dys7g-0003QU-GF for ecrit@ietf.org; Sat, 30 Jul 2005 10:15:32 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41xp) by dx28.winwebhosting.com with esmtpa (Exim 4.51) id 1Dyrbd-0003wd-Up; Sat, 30 Jul 2005 08:42:26 -0500 From: "Brian Rosen" To: "'Cullen Jennings'" , Subject: RE: [Ecrit] schulzrinne-ecrit-lump high level model question Date: Sat, 30 Jul 2005 09:42:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWUqwBmKnWeuud8TduopM5cq6PF6QAXyKeQ In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f 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 Depends on your point of view. There is too much data for every = possible routing node to keep all of it. It is possible to keep enough of it = that the probability you will have what you need is fairly large. The = mechanisms have to be there to work when caching fails. My usual example is a call from a caf=E9 with a wifi hotspot through a = VPN tunnel to an enterprise VoIP system, where the caf=E9 is in Chicago and = the VoIP system is in Sierra Leone. The Sierra Leone system can reasonably = keep all the routing data for Sierra Leone, and possibly surrounding areas, = or frequently encountered areas. It can't keep route data for any place = any of its employees could possibly visit. The reverse occurs. The Chicago = system can reasonably cache the state of Illinois, and surrounding areas. With some effort, it could cache all of the U.S. It's not reasonable to = cache the entire globe with present systems. The data does not change all that often. Propagating change is probably = not too bad from the point of view of frequency of change, although the = number of potential routing elements is large, so if you did that, you need a pretty robust system. Queries need to be fast in human terms. Two seconds is a very long time = to wait for a ring when it's an emergency. We deal with 6-8 seconds now in some circumstances. Probably it's okay to have the outlier cases take a = few extra seconds. Better not happen too often though. Clearly, you want routing to work when things fail. That's pretty = important I think. It's one of the big reasons I keep pushing the DNS idea even though I know a lot of people have negative reactions. The thing is, we know it works when lots of things fail. No other idea we have talked = about has that characteristic. Most of them have never even been deployed in = any scale like what we are discussing. We simply don't know what will = happen. To me, that's a really poor idea. Better to use DNS. I think the LUMP idea has a lot of merit. I think it might work really well. I think it does have the kind of tradeoffs needed for the = problem, and I think some decent implementations that did some proactive caching would probably help. I think it has better tradeoffs than the IRIS approach. I don't have anywhere near the confidence I would have in the = DNS that it will though, and I think that's a very poor tradeoff for this application. You have to ask yourself: If it was my call, or my daughter's call, and there was some really big disturbance in the force, what would I want to depend on working - IRIS, LUMP, or DNS? Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Cullen Jennings Sent: Friday, July 29, 2005 11:48 PM To: ecrit@ietf.org Subject: [Ecrit] schulzrinne-ecrit-lump high level model question It seems that you have a whole bunch of hierarchal distributed data and = are trying to make a localized query against it. There are two basic = approaches, one would be to (as this draft) suggests, distribute the query so it = moves through hierarchy and finds the answer. The other approach would be to = move the data thought the hierarchy so everyone had a copy of all it and = could resolve the query. Some things that might choose between these two approaches are 1) is it too much data to keep a copy of all of it 2) is the data changing too frequently to propagate accurate copies of = it 3) how quick to the queries need to be (classic time/space tradeoff) 4) how many nodes have to be "up" and reachable for a query to succeed I guess my question is, are the two approaches I suggest both possible, = and if so, which one is the right one for the 911 problem. _______________________________________________ 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 Jul 30 10:07:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dyrzd-0001Uz-HZ; Sat, 30 Jul 2005 10:07:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dyrzc-0001Uu-Oy for ecrit@megatron.ietf.org; Sat, 30 Jul 2005 10:07: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 KAA11093 for ; Sat, 30 Jul 2005 10:07:11 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DysVU-00048P-Lw for ecrit@ietf.org; Sat, 30 Jul 2005 10:40:09 -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 j6UE62sw027467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 30 Jul 2005 10:06:02 -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 j6UE61hH023713; Sat, 30 Jul 2005 10:06:01 -0400 Message-ID: <42EB894D.40000@cs.columbia.edu> Date: Sat, 30 Jul 2005 10:06:05 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Ecrit] schulzrinne-ecrit-lump high level model question 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, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 Just to add to Brian's note: LUMP tries to do a bit of both (query-to-data and data-to-querier), using caching, flooding and replication for the latter. This definitely needs more explanation and exploration. I don't think we can predict the mix, but need, in my opinion, have tools that allows us to shift the balance as bandwidth vs. storage vs. speed-of-data-change trade-offs change. Henning Cullen Jennings wrote: > It seems that you have a whole bunch of hierarchal distributed data and are > trying to make a localized query against it. There are two basic approaches, > one would be to (as this draft) suggests, distribute the query so it moves > through hierarchy and finds the answer. The other approach would be to move > the data thought the hierarchy so everyone had a copy of all it and could > resolve the query. > > Some things that might choose between these two approaches are > 1) is it too much data to keep a copy of all of it > 2) is the data changing too frequently to propagate accurate copies of it > 3) how quick to the queries need to be (classic time/space tradeoff) > 4) how many nodes have to be "up" and reachable for a query to succeed > > I guess my question is, are the two approaches I suggest both possible, and > if so, which one is the right one for the 911 problem. > > > > _______________________________________________ > 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 Jul 30 10:41:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DysWe-0000Oj-Oc; Sat, 30 Jul 2005 10:41:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DysWc-0000OZ-Sc for ecrit@megatron.ietf.org; Sat, 30 Jul 2005 10:41: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 KAA13907 for ; Sat, 30 Jul 2005 10:41:17 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dyt2V-0005MW-3U for ecrit@ietf.org; Sat, 30 Jul 2005 11:14:16 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 30 Jul 2005 07:41:08 -0700 X-IronPort-AV: i="3.95,154,1120460400"; d="scan'208"; a="201669070:sNHT25300776" Received: from sea-alpha-e2k3.sea-alpha.cisco.com (sea-alpha-e2k3.cisco.com [10.93.132.88]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6UEf8JL010899 for ; Sat, 30 Jul 2005 07:41:08 -0700 (PDT) Received: from FluffyNotebootk ([171.68.225.134]) by sea-alpha-e2k3.sea-alpha.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 30 Jul 2005 07:45:44 -0700 From: "Cullen Jennings" To: Date: Sat, 30 Jul 2005 10:41:15 -0400 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWVFLQNCcGsOkNMTvq7UIJoR0Q8AQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-OriginalArrivalTime: 30 Jul 2005 14:45:44.0390 (UTC) FILETIME=[5D685E60:01C59515] X-Spam-Score: 1.1 (+) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [Ecrit] hardie-ecrit-iris-02 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 random thought trivial nit but ... I was thinking about some other code that parsed a list of different URI and how long that list got and some bugs in parsing. It made me wonder if the query should specify the URI types the device understands and the response should have only those types. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jul 30 10:55:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyskX-0003s8-NX; Sat, 30 Jul 2005 10:55:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyskW-0003s3-Il for ecrit@megatron.ietf.org; Sat, 30 Jul 2005 10:55: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 KAA14686 for ; Sat, 30 Jul 2005 10:55:38 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DytGM-0005tL-VO for ecrit@ietf.org; Sat, 30 Jul 2005 11:28:38 -0400 Received: from [10.0.1.2] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Sat, 30 Jul 2005 10:55:33 -0400 id 001FF674.42EB94E5.00003803 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <61FEE1B9-E58F-473E-857B-3DCB0298BBF4@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] hardie-ecrit-iris-02 Date: Sat, 30 Jul 2005 10:55:31 -0400 To: Cullen Jennings X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 Jul 30, 2005, at 10:41 AM, Cullen Jennings wrote: > This is a random thought trivial nit but ... I was thinking about > some other > code that parsed a list of different URI and how long that list got > and some > bugs in parsing. It made me wonder if the query should specify the > URI types > the device understands and the response should have only those types. That's not a bad idea. But I wonder just how many URI schemes we will end up supporting. My assumption is that there will be very few, possibly only one. But this parameter is an easy thing to add. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jul 30 21:29:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dz2e8-0004P4-60; Sat, 30 Jul 2005 21:29:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dz2e6-0004Ou-LP for ecrit@megatron.ietf.org; Sat, 30 Jul 2005 21:29: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 VAA08707 for ; Sat, 30 Jul 2005 21:29:41 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dz3A4-0000kj-F2 for ecrit@ietf.org; Sat, 30 Jul 2005 22:02:45 -0400 Received: from zctwc060.asiapac.nortel.com (zctwc060.asiapac.nortel.com [47.153.200.67]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j6V1Srd00279; Sat, 30 Jul 2005 20:28:53 -0500 (CDT) Received: by zctwc060.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 31 Jul 2005 11:27:33 +1000 Message-ID: From: "James Winterbottom" To: Henning Schulzrinne Date: Sun, 31 Jul 2005 11:27:33 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.8 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ecrit@ietf.org Subject: [Ecrit] LUMP support for Location by Reference 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="===============1528535604==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1528535604== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5956F.06A37EB6" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5956F.06A37EB6 Content-Type: text/plain Hi Henning, I see that LUMP passes the PIDF document up to the resolver, have you thought about support for passing a location reference to the resolver over LUMP also? Cheers James ------_=_NextPart_001_01C5956F.06A37EB6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable LUMP support for Location by Reference

Hi Henning,

I see that LUMP passes the PIDF document up to the = resolver, have you thought about support for passing a location = reference to the resolver over LUMP also?

Cheers
James

------_=_NextPart_001_01C5956F.06A37EB6-- --===============1528535604== 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 --===============1528535604==-- From ecrit-bounces@ietf.org Sun Jul 31 02:55:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dz7jJ-0008Rk-LT; Sun, 31 Jul 2005 02:55:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dz7jH-0008Rf-Th for ecrit@megatron.ietf.org; Sun, 31 Jul 2005 02:55: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 CAA09551 for ; Sun, 31 Jul 2005 02:55:22 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dz8FH-0001yD-Dm for ecrit@ietf.org; Sun, 31 Jul 2005 03:28:29 -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 j6V6tCQc011241 for ; Sun, 31 Jul 2005 08:55:12 +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 j6V6tBKI022688 for ; Sun, 31 Jul 2005 08:55:11 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Sun, 31 Jul 2005 08:55:11 +0200 Content-class: urn:content-classes:message 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 Date: Sun, 31 Jul 2005 08:54:41 +0200 Message-ID: Thread-Topic: dns tutorial Thread-Index: AcWVnLlVKYwAQDDiRaa2Dw6rZvnLlw== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 31 Jul 2005 06:55:11.0676 (UTC) FILETIME=[CBCFD7C0:01C5959C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] dns tutorial 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 some of you might want to attend the DNS Tutorial in Room 353 today (1500-1700).=20 It is just a reminder since we will have a discussion about the DNS-SOS proposal.=20 Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jul 31 06:00:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzAbw-0005X3-GB; Sun, 31 Jul 2005 06:00:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzAbv-0005Wu-1b for ecrit@megatron.ietf.org; Sun, 31 Jul 2005 05:59: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 FAA14553 for ; Sun, 31 Jul 2005 05:59:56 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzB7x-0003lx-GE for ecrit@ietf.org; Sun, 31 Jul 2005 06:33:06 -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 j6V9xssw010422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 31 Jul 2005 05:59:54 -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 j6V9xr4p006649; Sun, 31 Jul 2005 05:59:53 -0400 Message-ID: <42ECA11B.5040809@cs.columbia.edu> Date: Sun, 31 Jul 2005 05:59:55 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Winterbottom 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org Subject: [Ecrit] Re: LUMP support for Location by Reference 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 Can't say that I've thought about details, but this doesn't seem particularly difficult. Good suggestion... James Winterbottom wrote: > Hi Henning, > > I see that LUMP passes the PIDF document up to the resolver, have you > thought about support for passing a location reference to the resolver > over LUMP also? > > Cheers > James > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jul 31 06:31:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzB66-0003af-Lb; Sun, 31 Jul 2005 06:31:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzB64-0003aR-Vo for ecrit@megatron.ietf.org; Sun, 31 Jul 2005 06:31: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 GAA15652 for ; Sun, 31 Jul 2005 06:31:06 -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 1DzBc7-0004o9-L7 for ecrit@ietf.org; Sun, 31 Jul 2005 07:04:16 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 31 Jul 2005 03:30:59 -0700 X-IronPort-AV: i="3.95,155,1120460400"; d="scan'208"; a="327629005:sNHT26416364" Received: from sea-alpha-e2k3.sea-alpha.cisco.com (sea-alpha-e2k3.cisco.com [10.93.132.88]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6VAUwJL003180; Sun, 31 Jul 2005 03:30:58 -0700 (PDT) Received: from FluffyNotebootk ([171.68.225.134]) by sea-alpha-e2k3.sea-alpha.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 31 Jul 2005 03:35:34 -0700 From: "Cullen Jennings" To: "'Brian Rosen'" , Subject: RE: [Ecrit] schulzrinne-ecrit-lump high level model question Date: Sun, 31 Jul 2005 12:30:47 +0200 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWUqwBmKnWeuud8TduopM5cq6PF6QAXyKeQABpsGyA= In-Reply-To: <40qjfr$2j9926@sj-inbound-b.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-OriginalArrivalTime: 31 Jul 2005 10:35:34.0898 (UTC) FILETIME=[95776520:01C595BB] X-Spam-Score: 1.1 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 > You have to ask yourself: If it was my call, or my daughter's > call, and > there was some really big disturbance in the force, what > would I want to > depend on working - IRIS, LUMP, or DNS? I'd want to depend on the one that if it failed, would cause all kinds of people who write cheques to providers to go berserk and demand it get fixed. When the garbage collectors go on strike, everyone notices and it gets fixed. When the hockey players go on strike, no one really cares. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jul 31 06:38:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzBDD-0004U1-Gy; Sun, 31 Jul 2005 06:38:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzBDB-0004Tg-M8 for ecrit@megatron.ietf.org; Sun, 31 Jul 2005 06:38:29 -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 GAA16119 for ; Sun, 31 Jul 2005 06:38:26 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzBjD-00054g-SG for ecrit@ietf.org; Sun, 31 Jul 2005 07:11:37 -0400 Received: from zctwc060.asiapac.nortel.com (zctwc060.asiapac.nortel.com [47.153.200.67]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j6VAc1h20540; Sun, 31 Jul 2005 05:38:02 -0500 (CDT) Received: by zctwc060.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 31 Jul 2005 20:38:01 +1000 Message-ID: From: "James Winterbottom" To: Cullen Jennings , "'Brian Rosen'" , ecrit@ietf.org Subject: RE: [Ecrit] schulzrinne-ecrit-lump high level model question Date: Sun, 31 Jul 2005 20:38:00 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 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="===============1284180130==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1284180130== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C595BB.EBF994F4" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C595BB.EBF994F4 Content-Type: text/plain True enough. But if you have a protocol that is restricted to emergency services, the problem is likely to be that since the call volumes are low, the complaint levels are even lower. If you pick something that is required for a lot of services, then when it doesn't work the complaint volumes will be higher, and garbage will get collected sooner. -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Sunday, 31 July 2005 8:31 PM To: 'Brian Rosen'; ecrit@ietf.org Subject: RE: [Ecrit] schulzrinne-ecrit-lump high level model question > You have to ask yourself: If it was my call, or my daughter's call, > and there was some really big disturbance in the force, what > would I want to > depend on working - IRIS, LUMP, or DNS? I'd want to depend on the one that if it failed, would cause all kinds of people who write cheques to providers to go berserk and demand it get fixed. When the garbage collectors go on strike, everyone notices and it gets fixed. When the hockey players go on strike, no one really cares. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ------_=_NextPart_001_01C595BB.EBF994F4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Ecrit] schulzrinne-ecrit-lump high level model = question

True enough.

But if you have a protocol that is restricted to = emergency services, the problem is likely to be that since the call = volumes are low, the complaint levels are even lower. If you pick = something that is required for a lot of services, then when it doesn't = work the complaint volumes will be higher, and garbage will get = collected sooner.



-----Original Message-----
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ] On Behalf Of Cullen Jennings
Sent: Sunday, 31 July 2005 8:31 PM
To: 'Brian Rosen'; ecrit@ietf.org
Subject: RE: [Ecrit] schulzrinne-ecrit-lump high = level model question



> You have to ask yourself: If it was my call, or = my daughter's call,
> and there was some really big disturbance in = the force, what
> would I want to
> depend on working - IRIS, LUMP, or DNS?

I'd want to depend on the one that if it failed, = would cause all kinds of people who write cheques to providers to go = berserk and demand it get fixed.


When the garbage collectors go on strike, everyone = notices and it gets fixed. When the hockey players go on strike, no one = really cares.



_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

------_=_NextPart_001_01C595BB.EBF994F4-- --===============1284180130== 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 --===============1284180130==-- From ecrit-bounces@ietf.org Sun Jul 31 06:39:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzBE2-0004js-1G; Sun, 31 Jul 2005 06:39:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzBE0-0004jh-Lv for ecrit@megatron.ietf.org; Sun, 31 Jul 2005 06:39: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 GAA16210 for ; Sun, 31 Jul 2005 06:39:17 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzBk3-00057B-6H for ecrit@ietf.org; Sun, 31 Jul 2005 07:12:28 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 31 Jul 2005 12:39:10 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6VAd7Dg007397 for ; Sun, 31 Jul 2005 12:39:07 +0200 (MEST) Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 31 Jul 2005 12:39:06 +0200 Received: from [86.255.25.104] ([10.58.48.33]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 31 Jul 2005 12:39:06 +0200 Message-ID: <42EC3917.2070502@cisco.com> Date: Sat, 30 Jul 2005 22:36:07 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2005 10:39:06.0566 (UTC) FILETIME=[13A15E60:01C595BC] X-Spam-Score: 0.6 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Subject: [Ecrit] questions and comments on LUMP 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 gave LUMP a read; here are some thoughts and comments. I've not been following list discussion that closely so I apologize if much of this has been discussed. There are really two separate parts to LUMP; one is a query protocol, and the other is a routing and distribution protocol. I had a hard time figuring out exactly how the latter aspect of lump worked. It would seem that many of the questions and issues around traditional routing algorithms would apply. Is the routing done by distance-vector approaches or link-state flooding? How is route aggregation done? How does the system deal with node failures? How are peering relationships established and maintained? I also couldn't figure out if caching played a role here. Can a query be cached? How is the cache invalidated? I would also be particularly worried about elements injecting fake information into the lump network. xmldsig provides a framework for authenticating the source of the data, but how does one make a reasonable decision around authorization? It would seem that the more loosely organized structure you have in mind for LUMP is at odds with the kind of authorization models you need. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jul 31 12: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 1DzHAB-0004aW-HI; Sun, 31 Jul 2005 12: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 1DzHAA-0004ZA-Ih for ecrit@megatron.ietf.org; Sun, 31 Jul 2005 12: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 MAA07105 for ; Sun, 31 Jul 2005 12:59:43 -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 1DzHgG-0004YU-Hl for ecrit@ietf.org; Sun, 31 Jul 2005 13:32:57 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 31 Jul 2005 09:59:36 -0700 X-IronPort-AV: i="3.95,156,1120460400"; d="scan'208"; a="327662894:sNHT34640960" 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 j6VGxZJN027976 for ; Sun, 31 Jul 2005 09:59:35 -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); Sun, 31 Jul 2005 09:59:35 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.145.60]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 31 Jul 2005 09:59:34 -0700 Message-Id: <4.3.2.7.2.20050731111327.033f9f08@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 31 Jul 2005 11:59:30 -0500 To: ecrit@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 31 Jul 2005 16:59:35.0382 (UTC) FILETIME=[3AAA3F60:01C595F1] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Subject: [Ecrit] New Comments on ECRIT Reqs ID 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 have the following comments on the ECRIT Requirements -01 ID: Intro section, 5th pragraph: I don't understand this "identified/identifier" language. The device making the emergency call doesn't have to identify anything to it, but the device MUST make the emergency message identifiable to the next SIP element (to treat that message special). This isn't what's stated here. Intro section, 7th pragraph: I don't believe it is achievable to identify who is making the call attempt *in the protocol*. I can easily use Marc's SIP UA to call 911. The PSAP will think Marc is in trouble, right? The text here needs to be clarified for what it really wants. Intro section, 7th pragraph: I believe stating that "....most jurisdictions require something by law..." means there should be a reference *here* to that or those laws to justify this claim. Intro section, 8th pragraph should be rewritten to the following: "Emergency calls need to identify the location of the calling device (Section 5). Caller location needs to be identified for two purposes, namely to route the call set-up messages to the appropriate PSAP and to display the caller's location to the call taker to simplify dispatching emergency assistance to the correct location." Section 2, 2nd paragraph: "implement able" should be one word Section 2. I thought we agreed "AIP" was to change back to "IAP" to maintain consistency with "ISP". Section 2. ESRP - this definition seems to miss what it's really about: providing the correct Request-URI for either the appropriate PSAP, or of a next hop SIP element that will do this "mapping function" right. Section 2. ESRP - stating the ESRP would typically be a SIP Proxy or a B2BUA is redundant, because a B2BUA is an instance of a SIP Proxy. Section 2. "Location Key" - if we're going to have location by-reference, then this is a URI and not a key, and this document should start syaing as much. R6. needs to add "...once the URI is delivered to the device, complying with normal 3261 operations MUST be all that is necessary for that device to communicate with the PSAP." A3, second sentence: instead of "...routing to a PSAP.", it needs to be "...routing only to a PSAP." A6. What does this requirement have to do with Emergency Addressing? R6 above should cover this one regardless. Section 5. The three definitions (UA-inserted and UA-referenced and Proxy-inserted) are not mentioned again with this section, therefore should be removed. Section 6, second paragraph. I believe the contention that PSAP boundaries "change" often needs to be substantiated in some way. How often does this really occur? Once a year at most? This synchronization cannot therefore be mentioned like something to be afraid of I1. the must needs to be capitalized, MUST I13 - "proferred"? do you mean "preferred"? I3 and I31 appear to have some overlap with the URI being to a PSAP or another ESRP. I39 is contradictory to prior agreement that a call set-up, once started, doesn't get re-routed with a change in UAC location - but that it's up to the PSAP to receive this UPDATE in SIP to then transfer the call to the now correct PSAP. In SIP, this would cause the UAC to send a CANCEL to the first INVITE and generate a new INVITE, costing time from a live operator. "Reachback" can be up to 15 seconds into the call.... surely the SIP call is expected to be "up" by then, and no one expects the UAC to INVITE to a new PSAP, or do they here? D9 doesn't make clear where this mandatory-to-implement protocol is to be implemented. I'm not sure what the motivation is for SD2, SD3, SD4 or SD5, or where this is expected to be conveyed? Each of these requirements need to be clearer or deleted. Noticeably less comments this version, but I'm also noticing there is not a lot of synergies with the SIP Location Conveyance doc in a number of areas. 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 Jul 31 14:16:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzIM5-0003Ku-3S; Sun, 31 Jul 2005 14:16:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzIM3-0003Kk-V1 for ecrit@megatron.ietf.org; Sun, 31 Jul 2005 14:16: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 OAA10929 for ; Sun, 31 Jul 2005 14:16:06 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzIsB-0008W6-NE for ecrit@ietf.org; Sun, 31 Jul 2005 14:49:20 -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 j6VIDpsw005920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 31 Jul 2005 14:13:51 -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 j6VIDnQo007870; Sun, 31 Jul 2005 14:13:50 -0400 Message-ID: <42ED14E0.8060006@cs.columbia.edu> Date: Sun, 31 Jul 2005 14:13:52 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Ecrit] questions and comments on LUMP References: <42EC3917.2070502@cisco.com> In-Reply-To: <42EC3917.2070502@cisco.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: 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 Thanks for your comments; some responses below. Jonathan Rosenberg wrote: > There are really two separate parts to LUMP; one is a query protocol, > and the other is a routing and distribution protocol. I had a hard time > figuring out exactly how the latter aspect of lump worked. It would seem > that many of the questions and issues around traditional routing > algorithms would apply. Is the routing done by distance-vector > approaches or link-state flooding? How is route aggregation done? How > does the system deal with node failures? How are peering relationships > established and maintained? I fully admit that this needs a much better discussion. It's not nearly as complicated as (say) BGP routing - think of the top-level distribution as OSPF flooding, if you want to use a routing analogy. Node failures are fully transparent, with two levels of redundancy (cluster and flooding). Essentially, any first-level node is non-critical. You can have as many of those as you want. Analogy: DNS resolvers. > > I also couldn't figure out if caching played a role here. Can a query be > cached? How is the cache invalidated? Yes, queries are cached. Invalidation is done by replacement (top level) or timeout (anywhere else). > > I would also be particularly worried about elements injecting fake > information into the lump network. xmldsig provides a framework for > authenticating the source of the data, but how does one make a > reasonable decision around authorization? It would seem that the more > loosely organized structure you have in mind for LUMP is at odds with > the kind of authorization models you need. There are two somewhat separate problems for bogus information: conflicting information (e.g., two entities claiming authority for the nj.us tree) and information for some part of the earth that doesn't actually exist yet in the database. There are several possible solutions to the bogus database problem: signature from known-good sources and peering with known-good peer. There's a clear trade-off here: At one end, you can have a strict hierarchy with a root (DNS-style), but this requires global political agreement about the root. The ENUM and ICANN history provide two related examples that such agreement is not an easy one. The other is a more peering-oriented model where neighbors can trust each other, possibly mediated by a commercial or not-for-profit entity that vets such information. (It would know who is authorized to sign for nj.us and a voice service provider trusts its LUMP "service provider". It could be an organization such as NENA in the US.) I don't know which model will turn out to be more deployable and this may well change over time, so I want to be able to support both without re-starting protocol design. Since these involve very different business models, I'd rather not get into a design that only allows one such business model. > > Thanks, > Jonathan R. > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit