From ecrit-bounces@ietf.org Fri Sep 01 06:26:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ6EN-0004AO-L0; Fri, 01 Sep 2006 06:26:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ6EM-000496-Tv for ecrit@ietf.org; Fri, 01 Sep 2006 06:26:34 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ6EL-0006dG-MK for ecrit@ietf.org; Fri, 01 Sep 2006 06:26:34 -0400 Received: from [10.0.1.52] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Fri, 01 Sep 2006 06:26:19 -0400 id 0158838C.44F80ACB.000031F8 In-Reply-To: References: <05fa01c6cd65$cdf36830$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7B0F193C-AB85-4299-B1C7-385F8E80FAC4@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Re: How many people do we plan to kill Date: Fri, 1 Sep 2006 06:26:20 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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: , Errors-To: ecrit-bounces@ietf.org On Aug 31, 2006, at 11:19 PM, Henning Schulzrinne wrote: >>> We NEED to protect the query. I can't imagine designing a system >>> designed >>> for an end host to send its location in the clear for any purpose. >> >> I don't see much reason to design a system where the end host >> expects to fail authentication. And regarding this noble of idea >> of protecting my location at the risk of my life, I'd rather you not. > > I'm confused by this discussion. Are we discussing > > (1) protecting privacy of LoST queries for regular PSAP URLs? > > (2) protecting access to emergency-infrastructure information > ("what is the police commander URL for this point")? > > For (1), I just don't see the big deal with normal server-side TLS, > as this query will occur well before the emergency in almost all > cases and is thus not time-critical. This is also where privacy > seems to matter most, since most people would probably not want to > be tracked continuously. (The tracking isn't really continuous > since you'd only do a query when entering a new coverage region. > For most people, that's maybe once a day, during their commute.) First, Brian is not just talking about TLS with server certs. He has stated repeatedly the idea you mentioned, TLS using HTTP basic or digest authentication for normal use, and TLS with server and client certs for the special case. > For queries at the point of an emergency call, TLS with server-side > authentication seems harmless, as long as the client can decide to > ignore cert validation failures at that time. There is a low risk > of a MIM attack, but that's a reasonable trade-off, given the > alternatives. Given that the master secret, which is used to encrypt the session, is generated using the keys in the server's certificate, I do not believe it is possible for a client to simply ignore cert validation failures. Even it were, suggesting such a thing is bad practice. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 01 07:41:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ7O9-0000qe-QC; Fri, 01 Sep 2006 07:40:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ7O7-0000o5-Cj for ecrit@ietf.org; Fri, 01 Sep 2006 07:40:43 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ7H2-0006ZZ-CU for ecrit@ietf.org; Fri, 01 Sep 2006 07:33:25 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GJ7Gx-0002Xo-FB; Fri, 01 Sep 2006 06:33:19 -0500 From: "Brian Rosen" To: "'Andrew Newton'" , "'Henning Schulzrinne'" Subject: RE: [Ecrit] Re: How many people do we plan to kill Date: Fri, 1 Sep 2006 07:33:17 -0400 Message-ID: <066401c6cdba$6daad080$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <7B0F193C-AB85-4299-B1C7-385F8E80FAC4@hxr.us> Thread-Index: AcbNsRV8i5rV/nBES827UJujBFYPcwACDA5A X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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: , Errors-To: ecrit-bounces@ietf.org Andy I kept thinking I was missing something. At this point, I think you are missing something. The endpoint would first attempt to create a TLS connection. If that succeeded, then he would complete his "https" query. If it failed, he does an "http" query. All servers that I know of would support that. All client libraries that I know of would support that. For the moment (maybe forever) ignore my special case; we need to make sure we agree on the basic mechanism before we deal with special cases. The normal, should-work-every-time case is a TLS query with basic/digest authentication. There is a backup, completely at the option of the client, to run a no-security query and get the same response it would have if the TLS attempt had succeeded. The server doesn't care if you use TLS, the client does. The TLS query is on a different port than the non-TLS query, as it is on any similar server. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Friday, September 01, 2006 6:26 AM > To: Henning Schulzrinne > Cc: Brian Rosen; 'Ecrit@Ietf.Org' > Subject: Re: [Ecrit] Re: How many people do we plan to kill > > > On Aug 31, 2006, at 11:19 PM, Henning Schulzrinne wrote: > > >>> We NEED to protect the query. I can't imagine designing a system > >>> designed > >>> for an end host to send its location in the clear for any purpose. > >> > >> I don't see much reason to design a system where the end host > >> expects to fail authentication. And regarding this noble of idea > >> of protecting my location at the risk of my life, I'd rather you not. > > > > I'm confused by this discussion. Are we discussing > > > > (1) protecting privacy of LoST queries for regular PSAP URLs? > > > > (2) protecting access to emergency-infrastructure information > > ("what is the police commander URL for this point")? > > > > For (1), I just don't see the big deal with normal server-side TLS, > > as this query will occur well before the emergency in almost all > > cases and is thus not time-critical. This is also where privacy > > seems to matter most, since most people would probably not want to > > be tracked continuously. (The tracking isn't really continuous > > since you'd only do a query when entering a new coverage region. > > For most people, that's maybe once a day, during their commute.) > > First, Brian is not just talking about TLS with server certs. He has > stated repeatedly the idea you mentioned, TLS using HTTP basic or > digest authentication for normal use, and TLS with server and client > certs for the special case. > > > For queries at the point of an emergency call, TLS with server-side > > authentication seems harmless, as long as the client can decide to > > ignore cert validation failures at that time. There is a low risk > > of a MIM attack, but that's a reasonable trade-off, given the > > alternatives. > > Given that the master secret, which is used to encrypt the session, > is generated using the keys in the server's certificate, I do not > believe it is possible for a client to simply ignore cert validation > failures. Even it were, suggesting such a thing is bad practice. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 01 07:42:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ7PV-0001Tm-U3; Fri, 01 Sep 2006 07:42:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ7PU-0001TU-Gq for ecrit@ietf.org; Fri, 01 Sep 2006 07:42:08 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ7PU-0007gA-67 for ecrit@ietf.org; Fri, 01 Sep 2006 07:42:08 -0400 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by ns0.neustar.com (Postfix) with ESMTP id 26F0C32906; Fri, 1 Sep 2006 11:42:08 +0000 (GMT) Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Sep 2006 07:42:07 -0400 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 Subject: RE: [Ecrit] FW: LoST synchronous query and referals Date: Fri, 1 Sep 2006 07:42:03 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] FW: LoST synchronous query and referals Thread-Index: AcbNjE9QkHq9gcvhSCCBjxReRgz4PwALiBvA From: "Rosen, Brian" To: "Michael Haberler" X-OriginalArrivalTime: 01 Sep 2006 11:42:07.0839 (UTC) FILETIME=[A77096F0:01C6CDBB] X-Spam-Score: -2.8 (--) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f 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: , Errors-To: ecrit-bounces@ietf.org Michael The question I'm asking is not how long an HTTP query takes. The question I'm asking is how long a point-in-polygon operation takes. The question I raised was for a geo query. =20 I do thing the "avalanche restart" problem should be addressed in -phonebcp. I lost track of that, Jonathan was working on it. A very quick Google query shows it's mentioned in -outbound and -overload, but I don't see the randomization at the client end. Brian > -----Original Message----- > From: Michael Haberler [mailto:mah@inode.at] > Sent: Friday, September 01, 2006 2:03 AM > To: Rosen, Brian > Cc: Henning Schulzrinne; Ecrit@Ietf.Org > Subject: Re: [Ecrit] FW: LoST synchronous query and referals >=20 > Rosen, Brian schrieb: > > Do you really get a few millisecond response to a geo query with a full > > set of polygons? I thought it was a bit more (but not a whole lot > > more). > > > sub-5ms is doable with standard Apache / DBMS / PC platforms >=20 > I wouldnt be concerned much about steady-state load but more the convoy > effects after a major net outage, when many devices try to fetch > concurrently >=20 > analogy from my ISP past: an E3/T3 outage and re-sync on a fully loaded > dialup server used to have spectacular effects on the Radius servers (up > to 480 instantaneous session disconnects, and a clogged queue of access > requests/session starts thereafter) >=20 > this affects more the L7 location aquisition protocol than LoST, though >=20 > -Michael >=20 > > Brian > > > > > >> -----Original Message----- > >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >> Sent: Thursday, August 31, 2006 5:30 PM > >> To: Rosen, Brian > >> Cc: Ecrit@Ietf.Org > >> Subject: Re: [Ecrit] FW: LoST synchronous query and referals > >> > >> The difference between the response time for a loaded (but not > >> collapsing) and unloaded server is likely to be no more than 1:10, at > >> most. This is based on some extrapolation from SIP server measurements > >> we have done; in most systems, response time follows the classical > >> hockey stick trajectory, with an extremely rapid rise to infinity when > >> the load starts to exceed 80 or 90% of capacity. (The knee of the > >> > > curve > > > >> and the slopes depend on the variability of the arrival and service > >> process; details are in any book on queueing theory.) > >> > >> In other words, the chance that waiting a long time will help is > >> > > small. > > > >> The server is either operating in the 80%-or-below load and you'll get > >> an answer almost immediately or it is just as likely in the collapsing > >> phase where any amount of waiting isn't going to help much. For these > >> systems, it is much better to limit the queue size to a small number > >> (say, 10), as that prevents congestion collapse. Increasing the queue > >> size will not significantly improve the throughput. > >> > >> Example: For the classical M/M/1 system, a load of 0.9 produces a > >> > > queue > > > >> length of 10, so making the queue larger will only yield, at most, 10% > >> more throughput. 20 gives you 95%, 100 pushes it to 99% load, so lots > >> > > of > > > >> waiting for minuscule performance gains. (A real system is likely to > >> have smaller variability.) The TCP listen queue does this already; I > >> think it's typically set to 5. > >> > >> Typical service times without load should be on the order of a few > >> milliseconds if you want to support more than 100 request/seconds. > >> > > Thus, > > > >> a queue of 10 might yield you a waiting time of maybe 50 ms. > >> > >> In other words, not a major issue if the system design is at all > >> competent. > >> > >> Henning > >> > >> > >> Rosen, Brian wrote: > >> > >>> And I made the same mistake twice before Andy corrected me. > >>> > >>> -----Original Message----- > >>> From: Rosen, Brian > >>> Sent: Thursday, August 31, 2006 2:13 PM > >>> To: GEOPRIV > >>> Subject: LoST synchronous query and referals > >>> > >>> I think we all imagine the LoST server to be a synchronous > >>> query/response: from a single port open to the server, you send a > >>> > > query > > > >>> and wait for the response before sending another query. > >>> > >>> Give a little thought to system architecture, where we are expecting > >>> > > all > > > >>> devices to query LoST periodically (with periodicity in perhaps tens > >>> > > of > > > >>> hours to days), or when they move out of the region/boundary > >>> > > supplied. > > > >>> That makes the query load on the server fairly high, but not really > >>> > > too > > > >>> bad. Certainly, a synchronous response is still appropriate, with > >>> possibly the server permitting many simultaneous ports open. We do > >>> expect to see many non-authoritative copies of the authoritative > >>> > > data to > > > >>> spread load. > >>> > >>> Now, suppose there was a bulk querier. Could be a LIS periodically > >>> revalidating locations for example, but suppose it was the E-CSCF in > >>> > > a > > > >>> 3GPP environment. I chose that because response time there matters, > >>> > > and > > > >>> it may very well have more than one outstanding call at a time. > >>> > >>> Now, recall that there may be a referral mechanism: you ask a > >>> > > question, > > > >>> and the local server may not have the answer, but may refer to > >>> > > another > > > >>> server for resolution. We don't have details on that. > >>> > >>> If the query is actually forwarded by the original server, and the > >>> response comes back through that server, then we do have a problem? > >>> > > A > > > >>> query could take a long time to complete. Is that a problem worth > >>> worrying about? How do we address it? I'm not asking for an > >>> asynchronous query. I think that is the wrong direction. It may be > >>> that the referral is NOT a forward, but a redirect. That would make > >>> > > the > > > >>> server not have to wait to respond. > >>> > >>> I think a high volume querier could have multiple persistent TCP > >>> connections maintained (if the protocol is TCP based) and choose an > >>> available one as the way to handle the routine cases. If the server > >>> multithreads, that combination may even work for a long duration > >>> > > query. > > > >>> Brian > >>> > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/ecrit > >>> > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 01 08:05:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ7m4-00030X-D3; Fri, 01 Sep 2006 08:05:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ7m2-00030D-PS for ecrit@ietf.org; Fri, 01 Sep 2006 08:05:26 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ7m1-0002oK-JB for ecrit@ietf.org; Fri, 01 Sep 2006 08:05:26 -0400 Received: from [10.0.1.52] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Fri, 01 Sep 2006 08:05:17 -0400 id 0158841C.44F821FD.000042BA In-Reply-To: <7B0F193C-AB85-4299-B1C7-385F8E80FAC4@hxr.us> References: <05fa01c6cd65$cdf36830$640fa8c0@cis.neustar.com> <7B0F193C-AB85-4299-B1C7-385F8E80FAC4@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3D41EE6E-F870-4672-9A58-BFBDF1EE2868@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Re: How many people do we plan to kill Date: Fri, 1 Sep 2006 08:05:19 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: , Errors-To: ecrit-bounces@ietf.org This is what happens when you haven't had that first morning cup of coffee and decide to send email... On Sep 1, 2006, at 6:26 AM, Andrew Newton wrote: > Given that the master secret, which is used to encrypt the session, > is generated using the keys in the server's certificate, I do not > believe it is possible for a client to simply ignore cert > validation failures. Even it were, suggesting such a thing is bad > practice. As I understand it, the client can create a master secret with the suspect public key. But once you do that, you have essentially defeated TLS. Which means, you are going through the expensive exercise of TLS negotiation and cannot guarantee privacy. This is not a very good trade-off. An evil-twin could trivially take advantage of this with an off-the-shelf HTTP proxy. Given this, ROT13 might be more secure. :) And as I said, some TLS libraries WILL NOT allow the connection to go forward under these conditions. A quick look at JSSE, used by 99% of all Java programs which will likely constitute a huge number server- side XML-over-HTTP implementations (I don't know if J2ME includes JSSE, but if so then we are talking handsets as well), has no facility to say "ignore invalid peer certs". At least none that I could find in the Javadoc. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 01 08:19:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ7zM-0002W4-BK; Fri, 01 Sep 2006 08:19:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ7zL-0002Vy-3E for ecrit@ietf.org; Fri, 01 Sep 2006 08:19:11 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ7zJ-0002Yt-T8 for ecrit@ietf.org; Fri, 01 Sep 2006 08:19:11 -0400 Received: from [10.0.1.52] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Fri, 01 Sep 2006 08:13:56 -0400 id 0158841A.44F82404.00004477 In-Reply-To: <066401c6cdba$6daad080$640fa8c0@cis.neustar.com> References: <066401c6cdba$6daad080$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <764379D0-191A-42F5-9817-32EE176B47F5@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Re: How many people do we plan to kill Date: Fri, 1 Sep 2006 08:13:58 -0400 To: Brian Rosen X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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: , Errors-To: ecrit-bounces@ietf.org On Sep 1, 2006, at 7:33 AM, Brian Rosen wrote: > Andy > > I kept thinking I was missing something. At this point, I think > you are > missing something. > > The endpoint would first attempt to create a TLS connection. If that > succeeded, then he would complete his "https" query. > > If it failed, he does an "http" query. > > All servers that I know of would support that. All client > libraries that I > know of would support that. Oh, I think I understand what you are saying. And no client library that I know of supports this out of the box. The LoST application will have to specifically employ this retry logic. > For the moment (maybe forever) ignore my special case; we need to > make sure > we agree on the basic mechanism before we deal with special cases. Is your special case the paragraph that follows? Because I'll happily ignore it if it is not up for consideration. > The normal, should-work-every-time case is a TLS query with basic/ > digest > authentication. There is a backup, completely at the option of the > client, > to run a no-security query and get the same response it would have > if the > TLS attempt had succeeded. The server doesn't care if you use TLS, > the > client does. The TLS query is on a different port than the non-TLS > query, > as it is on any similar server. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 01 08:23:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ832-0005hm-UA; Fri, 01 Sep 2006 08:23:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ831-0005gy-1l for ecrit@ietf.org; Fri, 01 Sep 2006 08:22:59 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ82y-0002kN-RK for ecrit@ietf.org; Fri, 01 Sep 2006 08:22:59 -0400 Received: from [192.168.0.41] (pool-138-89-38-92.mad.east.verizon.net [138.89.38.92]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k81CMqxf016125 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 1 Sep 2006 08:22:53 -0400 (EDT) In-Reply-To: <7B0F193C-AB85-4299-B1C7-385F8E80FAC4@hxr.us> References: <05fa01c6cd65$cdf36830$640fa8c0@cis.neustar.com> <7B0F193C-AB85-4299-B1C7-385F8E80FAC4@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5129508A-CFFE-4043-A765-B652DC07334B@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Re: How many people do we plan to kill Date: Fri, 1 Sep 2006 08:22:42 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.2) X-PerlMx-Spam: Gauge=XXII, Probability=22%, X-Seen-By filter2.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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: , Errors-To: ecrit-bounces@ietf.org > Given that the master secret, which is used to encrypt the session, > is generated using the keys in the server's certificate, I do not > believe it is possible for a client to simply ignore cert > validation failures. Even it were, suggesting such a thing is bad > practice. > I agree that ignoring these is bad practice and one would hope that something as critical as LoST servers is operated by professionals, rather than the police chief's nephew who otherwise mows grass for a living, but at least in some cases, web browsers allow users to ignore expired certs, mismatched certs or certs with unrecognized CAs. Not good, but clearly established practice, given that the alternative is no service. What's your alternative? > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 01 09:55:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ9Ul-0002XZ-Ty; Fri, 01 Sep 2006 09:55:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ9Uk-0002Wt-KK for ecrit@ietf.org; Fri, 01 Sep 2006 09:55:42 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ9Ui-0006L6-ET for ecrit@ietf.org; Fri, 01 Sep 2006 09:55:42 -0400 Received: from [10.0.1.52] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Fri, 01 Sep 2006 09:55:32 -0400 id 015880D3.44F83BD4.0000574F In-Reply-To: <5129508A-CFFE-4043-A765-B652DC07334B@cs.columbia.edu> References: <05fa01c6cd65$cdf36830$640fa8c0@cis.neustar.com> <7B0F193C-AB85-4299-B1C7-385F8E80FAC4@hxr.us> <5129508A-CFFE-4043-A765-B652DC07334B@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <67F295E3-9E00-4B82-835D-6999F50768A7@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Re: How many people do we plan to kill Date: Fri, 1 Sep 2006 09:55:33 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed 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: , Errors-To: ecrit-bounces@ietf.org On Sep 1, 2006, at 8:22 AM, Henning Schulzrinne wrote: > What's your alternative? Do not specify bad practices. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 01 10:09:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ9iG-0000Fb-P7; Fri, 01 Sep 2006 10:09:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ9iD-0000Cf-OG for ecrit@ietf.org; Fri, 01 Sep 2006 10:09:37 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ9iC-00074n-II for ecrit@ietf.org; Fri, 01 Sep 2006 10:09:37 -0400 Received: from [10.0.1.52] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Fri, 01 Sep 2006 09:59:26 -0400 id 015880D3.44F83CBE.00005818 In-Reply-To: <066f01c6cdc1$7fa59ca0$640fa8c0@cis.neustar.com> References: <066f01c6cdc1$7fa59ca0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Re: How many people do we plan to kill Date: Fri, 1 Sep 2006 09:59:27 -0400 To: Brian Rosen X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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: , Errors-To: ecrit-bounces@ietf.org On Sep 1, 2006, at 8:23 AM, Brian Rosen wrote: > I agree that there is no off the shelf client library that > automatically > retries a failed TLS operation by attempting a plain TCP operation, > but I > think it's about 2 or 3 lines of code, in the application, to do it. > > The last paragraph is not the special case; it's the normal case. > The normal case is TLS with basic/digest so that the query gets > privacy and > integrity protection when sending its location and getting its > emergency > call URI. Its backup, if it needs to and wants to, is to try the > operation > again as a plain TCP query, with no protection. Ignoring the TLS part for a second, just why is HTTP basic or digest authentication necessary? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 01 10:12:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ9lA-0008Uz-9j; Fri, 01 Sep 2006 10:12:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ9l8-0008Ao-6o for ecrit@ietf.org; Fri, 01 Sep 2006 10:12:38 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ9l6-0007Cx-0F for ecrit@ietf.org; Fri, 01 Sep 2006 10:12:38 -0400 Received: from lion.cs.columbia.edu (IDENT:vHW6MsSYj/sHV/AJ66b695ZSJde+R+UY@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k81ECVGb002598 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 1 Sep 2006 10:12:31 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k81ECUg7018002 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 1 Sep 2006 10:12:30 -0400 Message-ID: <44F83FC9.3020206@cs.columbia.edu> Date: Fri, 01 Sep 2006 10:12:25 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] Re: How many people do we plan to kill References: <06a001c6cdcf$7d36b720$640fa8c0@cis.neustar.com> In-Reply-To: <06a001c6cdcf$7d36b720$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter2.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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: , Errors-To: ecrit-bounces@ietf.org I don't get it. TLS server-certs does just that. Digest or Basic add no certainty in this regard. I suspect we're all talking past each other at this point. Brian Rosen wrote: > To establish a security association that the client reasonably trusts the > server. The server will always trust the client. You then need to create a > shared secret to use for the privacy key based on the SA. > > Brian > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 01 10:19:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ9rW-0002e0-DM; Fri, 01 Sep 2006 10:19:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ9rV-0002du-99 for ecrit@ietf.org; Fri, 01 Sep 2006 10:19:13 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ9rU-0007WJ-37 for ecrit@ietf.org; Fri, 01 Sep 2006 10:19:13 -0400 Received: from [10.0.1.52] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Fri, 01 Sep 2006 10:09:01 -0400 id 015880D5.44F83EFD.00005A85 In-Reply-To: <06a001c6cdcf$7d36b720$640fa8c0@cis.neustar.com> References: <06a001c6cdcf$7d36b720$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Re: How many people do we plan to kill Date: Fri, 1 Sep 2006 10:09:02 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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: , Errors-To: ecrit-bounces@ietf.org On Sep 1, 2006, at 10:04 AM, Brian Rosen wrote: > To establish a security association that the client reasonably > trusts the > server. The server will always trust the client. You then need to > create a > shared secret to use for the privacy key based on the SA. >> >> Ignoring the TLS part for a second, just why is HTTP basic or digest >> authentication necessary? >> >> -andy > What?! Isn't that what TLS is suppose to do? I don't hold myself out as a security expert, but I would be hugely surprized if HTTP authentication isn't about the server trusting the client. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 01 10:20:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ9sk-0003B3-Oh; Fri, 01 Sep 2006 10:20:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ9sj-0003Ay-IG for ecrit@ietf.org; Fri, 01 Sep 2006 10:20:29 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ9si-0007ar-CY for ecrit@ietf.org; Fri, 01 Sep 2006 10:20:29 -0400 Received: from [10.0.1.52] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Fri, 01 Sep 2006 10:20:24 -0400 id 015880D3.44F841A8.00005D9B In-Reply-To: <44F83FC9.3020206@cs.columbia.edu> References: <06a001c6cdcf$7d36b720$640fa8c0@cis.neustar.com> <44F83FC9.3020206@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4A9B3EF7-42D0-4CCB-9D85-E9C68ADB1E77@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Re: How many people do we plan to kill Date: Fri, 1 Sep 2006 10:20:23 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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: , Errors-To: ecrit-bounces@ietf.org On Sep 1, 2006, at 10:12 AM, Henning Schulzrinne wrote: > I suspect we're all talking past each other at this point. Well, at least we have agreement on this. I'll try to write up my thoughts on this in another thread. So far, all I've done is sniped at Brian. I should really try to explain myself better. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 01 10:22:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ9uM-0004DY-Dk; Fri, 01 Sep 2006 10:22:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ9uL-0004D0-D1 for ecrit@ietf.org; Fri, 01 Sep 2006 10:22:09 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ8Tv-0003sp-S6 for ecrit@ietf.org; Fri, 01 Sep 2006 08:50:47 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GJ841-0000Ec-DI for ecrit@ietf.org; Fri, 01 Sep 2006 08:24:02 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GJ83w-0006gE-8t; Fri, 01 Sep 2006 07:23:56 -0500 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: [Ecrit] Re: How many people do we plan to kill Date: Fri, 1 Sep 2006 08:23:55 -0400 Message-ID: <066f01c6cdc1$7fa59ca0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <764379D0-191A-42F5-9817-32EE176B47F5@hxr.us> Thread-Index: AcbNwBqUaPn9ifAfSSOnvYX7Ezfp2gAAKTCw X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: -2.5 (--) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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: , Errors-To: ecrit-bounces@ietf.org I agree that there is no off the shelf client library that automatically retries a failed TLS operation by attempting a plain TCP operation, but I think it's about 2 or 3 lines of code, in the application, to do it. The last paragraph is not the special case; it's the normal case. The normal case is TLS with basic/digest so that the query gets privacy and integrity protection when sending its location and getting its emergency call URI. Its backup, if it needs to and wants to, is to try the operation again as a plain TCP query, with no protection. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Friday, September 01, 2006 8:14 AM > To: Brian Rosen > Cc: 'Henning Schulzrinne'; 'Ecrit@Ietf.Org' > Subject: Re: [Ecrit] Re: How many people do we plan to kill > > > On Sep 1, 2006, at 7:33 AM, Brian Rosen wrote: > > > Andy > > > > I kept thinking I was missing something. At this point, I think > > you are > > missing something. > > > > The endpoint would first attempt to create a TLS connection. If that > > succeeded, then he would complete his "https" query. > > > > If it failed, he does an "http" query. > > > > All servers that I know of would support that. All client > > libraries that I > > know of would support that. > > Oh, I think I understand what you are saying. And no client library > that I know of supports this out of the box. The LoST application > will have to specifically employ this retry logic. > > > For the moment (maybe forever) ignore my special case; we need to > > make sure > > we agree on the basic mechanism before we deal with special cases. > > Is your special case the paragraph that follows? Because I'll > happily ignore it if it is not up for consideration. > > > The normal, should-work-every-time case is a TLS query with basic/ > > digest > > authentication. There is a backup, completely at the option of the > > client, > > to run a no-security query and get the same response it would have > > if the > > TLS attempt had succeeded. The server doesn't care if you use TLS, > > the > > client does. The TLS query is on a different port than the non-TLS > > query, > > as it is on any similar server. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 01 10:29:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJA15-0006fa-U5; Fri, 01 Sep 2006 10:29:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJA14-0006de-Os for ecrit@ietf.org; Fri, 01 Sep 2006 10:29:06 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJA12-00086d-6h for ecrit@ietf.org; Fri, 01 Sep 2006 10:29:06 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 01 Sep 2006 10:29:04 -0400 X-IronPort-AV: i="4.08,201,1154923200"; d="scan'208"; a="100241544:sNHT32740680" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k81ET3Qe024420; Fri, 1 Sep 2006 10:29:03 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k81ET3dO012747; Fri, 1 Sep 2006 10:29:03 -0400 (EDT) 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.1830); Fri, 1 Sep 2006 10:29:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Re: How many people do we plan to kill Date: Fri, 1 Sep 2006 10:29:02 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301E4E0D5@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: How many people do we plan to kill Thread-Index: AcbNwBqUaPn9ifAfSSOnvYX7Ezfp2gAAKTCwAARnW4A= From: "Michael Hammer \(mhammer\)" To: "Brian Rosen" , "Andrew Newton" X-OriginalArrivalTime: 01 Sep 2006 14:29:03.0451 (UTC) FILETIME=[F935B2B0:01C6CDD2] DKIM-Signature: a=rsa-sha1; q=dns; l=3746; t=1157120943; x=1157984943; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Ecrit]=20Re=3A=20How=20many=20people=20do=20we=20plan=20to=20ki ll |To:=22Brian=20Rosen=22=20, =20=22Andrew=20Newton=22=20; X=v=3Dcisco.com=3B=20h=3DvFkIJTtbSxF43vh0c3TClDlXJHM=3D; b=cpzVN6kZz5kOV9li/JOh6kzwTSvBoUGO/BXynKQ4d65deRV/urUAWoWBef4jlFwG1vleljkL jIhMKcwW0cUBRkxiQUuHmxd2SC2xP8+DA3+UlNSSPP4YV87bLWxpRcGD; Authentication-Results: rtp-dkim-2.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f 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: , Errors-To: ecrit-bounces@ietf.org Brian, >From the peanut gallery: My impression just from reading this thread is that there are two cases being considered: 1) 90% - does not require any security, just requires an input to result in some public information, 2) 10% - requires security to protect some data from being given out to a select group of people. The solution proposed seems to focus first on catering to the 10%, and telling the other 90% that if you jump through the hoops and it doesn't work, try an alternate unprotected means. That seems backwards to me. It seems like the 90% path should be tried first, and if the data turns out to require a higher degree of protection, the system challenges the requestor to authenticate themselves and move to a confidential mode of exchanging the information. Is that the case? Mike =20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Friday, September 01, 2006 8:24 AM > To: 'Andrew Newton' > Cc: 'Ecrit@Ietf.Org' > Subject: RE: [Ecrit] Re: How many people do we plan to kill >=20 > I agree that there is no off the shelf client library that=20 > automatically retries a failed TLS operation by attempting a=20 > plain TCP operation, but I think it's about 2 or 3 lines of=20 > code, in the application, to do it.=20 >=20 > The last paragraph is not the special case; it's the normal case. > The normal case is TLS with basic/digest so that the query=20 > gets privacy and integrity protection when sending its=20 > location and getting its emergency call URI. Its backup, if=20 > it needs to and wants to, is to try the operation again as a=20 > plain TCP query, with no protection. >=20 > Brian >=20 > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Friday, September 01, 2006 8:14 AM > > To: Brian Rosen > > Cc: 'Henning Schulzrinne'; 'Ecrit@Ietf.Org' > > Subject: Re: [Ecrit] Re: How many people do we plan to kill > >=20 > >=20 > > On Sep 1, 2006, at 7:33 AM, Brian Rosen wrote: > >=20 > > > Andy > > > > > > I kept thinking I was missing something. At this point,=20 > I think you=20 > > > are missing something. > > > > > > The endpoint would first attempt to create a TLS connection. If=20 > > > that succeeded, then he would complete his "https" query. > > > > > > If it failed, he does an "http" query. > > > > > > All servers that I know of would support that. All=20 > client libraries=20 > > > that I know of would support that. > >=20 > > Oh, I think I understand what you are saying. And no=20 > client library=20 > > that I know of supports this out of the box. The LoST application=20 > > will have to specifically employ this retry logic. > >=20 > > > For the moment (maybe forever) ignore my special case; we need to=20 > > > make sure we agree on the basic mechanism before we deal with=20 > > > special cases. > >=20 > > Is your special case the paragraph that follows? Because=20 > I'll happily=20 > > ignore it if it is not up for consideration. > >=20 > > > The normal, should-work-every-time case is a TLS query=20 > with basic/=20 > > > digest authentication. There is a backup, completely at=20 > the option=20 > > > of the client, to run a no-security query and get the=20 > same response=20 > > > it would have if the TLS attempt had succeeded. The=20 > server doesn't=20 > > > care if you use TLS, the client does. The TLS query is on a=20 > > > different port than the non-TLS query, as it is on any similar=20 > > > server. > >=20 > > -andy >=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 Sep 01 10:34:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJA5x-0006C5-M9; Fri, 01 Sep 2006 10:34:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJA5w-000642-N2 for ecrit@ietf.org; Fri, 01 Sep 2006 10:34:08 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJA5v-0008KD-Cc for ecrit@ietf.org; Fri, 01 Sep 2006 10:34:08 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GJA5o-0000rT-8f; Fri, 01 Sep 2006 09:34:01 -0500 From: "Brian Rosen" To: "'Andrew Newton'" , "'Henning Schulzrinne'" Subject: RE: [Ecrit] Re: How many people do we plan to kill Date: Fri, 1 Sep 2006 10:33:56 -0400 Message-ID: <06b501c6cdd3$ab14d2e0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <066f01c6cdc1$7fa59ca0$640fa8c0@cis.neustar.com> Thread-Index: AcbNwBqUaPn9ifAfSSOnvYX7Ezfp2gAAKTCwAAShHXA= X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 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: , Errors-To: ecrit-bounces@ietf.org I have confused Andy and others by including HTTP auth and TLS-with-certs in the same sentence. Forget I said anything about http auth. Just think TLS-with-server-certs. Brian > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, September 01, 2006 8:24 AM > To: 'Andrew Newton' > Cc: 'Ecrit@Ietf.Org' > Subject: RE: [Ecrit] Re: How many people do we plan to kill > > I agree that there is no off the shelf client library that automatically > retries a failed TLS operation by attempting a plain TCP operation, but I > think it's about 2 or 3 lines of code, in the application, to do it. > > The last paragraph is not the special case; it's the normal case. > The normal case is TLS with basic/digest so that the query gets privacy > and > integrity protection when sending its location and getting its emergency > call URI. Its backup, if it needs to and wants to, is to try the > operation > again as a plain TCP query, with no protection. > > Brian > > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Friday, September 01, 2006 8:14 AM > > To: Brian Rosen > > Cc: 'Henning Schulzrinne'; 'Ecrit@Ietf.Org' > > Subject: Re: [Ecrit] Re: How many people do we plan to kill > > > > > > On Sep 1, 2006, at 7:33 AM, Brian Rosen wrote: > > > > > Andy > > > > > > I kept thinking I was missing something. At this point, I think > > > you are > > > missing something. > > > > > > The endpoint would first attempt to create a TLS connection. If that > > > succeeded, then he would complete his "https" query. > > > > > > If it failed, he does an "http" query. > > > > > > All servers that I know of would support that. All client > > > libraries that I > > > know of would support that. > > > > Oh, I think I understand what you are saying. And no client library > > that I know of supports this out of the box. The LoST application > > will have to specifically employ this retry logic. > > > > > For the moment (maybe forever) ignore my special case; we need to > > > make sure > > > we agree on the basic mechanism before we deal with special cases. > > > > Is your special case the paragraph that follows? Because I'll > > happily ignore it if it is not up for consideration. > > > > > The normal, should-work-every-time case is a TLS query with basic/ > > > digest > > > authentication. There is a backup, completely at the option of the > > > client, > > > to run a no-security query and get the same response it would have > > > if the > > > TLS attempt had succeeded. The server doesn't care if you use TLS, > > > the > > > client does. The TLS query is on a different port than the non-TLS > > > query, > > > as it is on any similar server. > > > > -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 Fri Sep 01 10:40:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJABm-00068l-Rh; Fri, 01 Sep 2006 10:40:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJABl-00068g-W9 for ecrit@ietf.org; Fri, 01 Sep 2006 10:40:10 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJABk-0000Aj-Ii for ecrit@ietf.org; Fri, 01 Sep 2006 10:40:09 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GJABd-0001FE-I8; Fri, 01 Sep 2006 09:40:02 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , "'Andrew Newton'" Subject: RE: [Ecrit] Re: How many people do we plan to kill Date: Fri, 1 Sep 2006 10:39:59 -0400 Message-ID: <06b601c6cdd4$82658550$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301E4E0D5@xmb-rtp-20b.amer.cisco.com> Thread-Index: AcbNwBqUaPn9ifAfSSOnvYX7Ezfp2gAAKTCwAARnW4AAAFX3AA== X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f 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: , Errors-To: ecrit-bounces@ietf.org Nope. 99% of the queries will be from end devices that want privacy and integrity protection. They will query with TLS-with-server-certs. IF THAT FAILS, and only if it fails, will they fall back to no TLS, no security, just a raw TCP based query. It's unacceptable, I think, for anyone to be sending their location in the clear, unless they can't get a privacy service to work. Then, and only then, can they make the tradeoff of, "do I send my location in the clear so I can progress the emergency call, or do I abandon the call if I can't protect my location privacy". I assume nearly all of us will choose the former, but, again, only after we try and fail to protect it. The 1% is the special case, and instead of TLS-with-server-certs, they will do TLS-with-client-certs. Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Friday, September 01, 2006 10:29 AM > To: Brian Rosen; Andrew Newton > Cc: Ecrit@Ietf.Org > Subject: RE: [Ecrit] Re: How many people do we plan to kill > > Brian, > > From the peanut gallery: > > My impression just from reading this thread is that there are two cases > being considered: > > 1) 90% - does not require any security, just requires an input to result > in some public information, > > 2) 10% - requires security to protect some data from being given out to > a select group of people. > > The solution proposed seems to focus first on catering to the 10%, and > telling the other 90% that if you jump through the hoops and it doesn't > work, try an alternate unprotected means. > > That seems backwards to me. It seems like the 90% path should be tried > first, and if the data turns out to require a higher degree of > protection, the system challenges the requestor to authenticate > themselves and move to a confidential mode of exchanging the > information. > > Is that the case? > > Mike > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Friday, September 01, 2006 8:24 AM > > To: 'Andrew Newton' > > Cc: 'Ecrit@Ietf.Org' > > Subject: RE: [Ecrit] Re: How many people do we plan to kill > > > > I agree that there is no off the shelf client library that > > automatically retries a failed TLS operation by attempting a > > plain TCP operation, but I think it's about 2 or 3 lines of > > code, in the application, to do it. > > > > The last paragraph is not the special case; it's the normal case. > > The normal case is TLS with basic/digest so that the query > > gets privacy and integrity protection when sending its > > location and getting its emergency call URI. Its backup, if > > it needs to and wants to, is to try the operation again as a > > plain TCP query, with no protection. > > > > Brian > > > > > -----Original Message----- > > > From: Andrew Newton [mailto:andy@hxr.us] > > > Sent: Friday, September 01, 2006 8:14 AM > > > To: Brian Rosen > > > Cc: 'Henning Schulzrinne'; 'Ecrit@Ietf.Org' > > > Subject: Re: [Ecrit] Re: How many people do we plan to kill > > > > > > > > > On Sep 1, 2006, at 7:33 AM, Brian Rosen wrote: > > > > > > > Andy > > > > > > > > I kept thinking I was missing something. At this point, > > I think you > > > > are missing something. > > > > > > > > The endpoint would first attempt to create a TLS connection. If > > > > that succeeded, then he would complete his "https" query. > > > > > > > > If it failed, he does an "http" query. > > > > > > > > All servers that I know of would support that. All > > client libraries > > > > that I know of would support that. > > > > > > Oh, I think I understand what you are saying. And no > > client library > > > that I know of supports this out of the box. The LoST application > > > will have to specifically employ this retry logic. > > > > > > > For the moment (maybe forever) ignore my special case; we need to > > > > make sure we agree on the basic mechanism before we deal with > > > > special cases. > > > > > > Is your special case the paragraph that follows? Because > > I'll happily > > > ignore it if it is not up for consideration. > > > > > > > The normal, should-work-every-time case is a TLS query > > with basic/ > > > > digest authentication. There is a backup, completely at > > the option > > > > of the client, to run a no-security query and get the > > same response > > > > it would have if the TLS attempt had succeeded. The > > server doesn't > > > > care if you use TLS, the client does. The TLS query is on a > > > > different port than the non-TLS query, as it is on any similar > > > > server. > > > > > > -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 Fri Sep 01 10:47:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJAIy-0000k8-IR; Fri, 01 Sep 2006 10:47:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJAIw-0000k3-KT for ecrit@ietf.org; Fri, 01 Sep 2006 10:47:34 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GJAIv-0000WX-6S for ecrit@ietf.org; Fri, 01 Sep 2006 10:47:34 -0400 Received: (qmail invoked by alias); 01 Sep 2006 14:47:31 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp039) with SMTP; 01 Sep 2006 16:47:31 +0200 X-Authenticated: #29516787 Message-ID: <44F84800.3080400@gmx.net> Date: Fri, 01 Sep 2006 16:47:28 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] Re: How many people do we plan to kill References: <06a001c6cdcf$7d36b720$640fa8c0@cis.neustar.com> <44F83FC9.3020206@cs.columbia.edu> <4A9B3EF7-42D0-4CCB-9D85-E9C68ADB1E77@hxr.us> In-Reply-To: <4A9B3EF7-42D0-4CCB-9D85-E9C68ADB1E77@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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: , Errors-To: ecrit-bounces@ietf.org Hi Andy, yes, please summarize the discussion. I don't really understand what the problem statement is, why we need to develop fancy security mechanisms, etc. (I am LoST.) Ciao Hannes Andrew Newton schrieb: > > On Sep 1, 2006, at 10:12 AM, Henning Schulzrinne wrote: > >> I suspect we're all talking past each other at this point. > > Well, at least we have agreement on this. > > I'll try to write up my thoughts on this in another thread. So far, all > I've done is sniped at Brian. I should really try to explain myself > better. > > -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 Fri Sep 01 10:50:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJALL-00056T-Bn; Fri, 01 Sep 2006 10:50:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJALK-00056N-1e for ecrit@ietf.org; Fri, 01 Sep 2006 10:50:02 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJALH-0000gg-K0 for ecrit@ietf.org; Fri, 01 Sep 2006 10:50:02 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 01 Sep 2006 07:49:59 -0700 X-IronPort-AV: i="4.08,201,1154934000"; d="scan'208"; a="39483553:sNHT35724036" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k81Enx7f008956; Fri, 1 Sep 2006 10:49:59 -0400 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 k81EnwdM023226; Fri, 1 Sep 2006 10:49:59 -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.1830); Fri, 1 Sep 2006 10:49:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Re: How many people do we plan to kill Date: Fri, 1 Sep 2006 10:49:58 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301E4E0E9@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: How many people do we plan to kill Thread-Index: AcbNwBqUaPn9ifAfSSOnvYX7Ezfp2gAAKTCwAARnW4AAAFX3AAAAWQuA From: "Michael Hammer \(mhammer\)" To: "Brian Rosen" , "Andrew Newton" X-OriginalArrivalTime: 01 Sep 2006 14:49:58.0949 (UTC) FILETIME=[E58B7D50:01C6CDD5] DKIM-Signature: a=rsa-sha1; q=dns; l=6128; t=1157122199; x=1157986199; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Ecrit]=20Re=3A=20How=20many=20people=20do=20we=20plan=20to=20ki ll |To:=22Brian=20Rosen=22=20, =20=22Andrew=20Newton=22=20; X=v=3Dcisco.com=3B=20h=3DvFkIJTtbSxF43vh0c3TClDlXJHM=3D; b=cB/z7ezMqt4pER0KEEewYkHiMBnQsX5CdxUau87Ws/KdfjF1C8UW6zM6xku7UIE/af+nicdx HG4UJAwQjwjqOhZf2GSAFjaEpJcqtYcuSPfya+WjtBOfnLdwqhj3ruhY; Authentication-Results: rtp-dkim-1.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 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: , Errors-To: ecrit-bounces@ietf.org Brian, That sounds like a logical argument for integrity and confidentiality.=20 So, the authentication aspects are secondary, correct? That is what threw me. The authentication would only be required if the response (jurisdicational data) for some reason was only to be given out to select clients. Your comments earlier suggested that the authentication would be done on all queries, and if that failed, then some fall-back action taken. Did I misread you on that? Mike > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Friday, September 01, 2006 10:40 AM > To: Michael Hammer (mhammer); 'Andrew Newton' > Cc: 'Ecrit@Ietf.Org' > Subject: RE: [Ecrit] Re: How many people do we plan to kill >=20 > Nope. >=20 > 99% of the queries will be from end devices that want privacy=20 > and integrity protection. They will query with=20 > TLS-with-server-certs. IF THAT FAILS, and only if it fails,=20 > will they fall back to no TLS, no security, just a raw TCP=20 > based query. It's unacceptable, I think, for anyone to be=20 > sending their location in the clear, unless they can't get a=20 > privacy service to work. > Then, and only then, can they make the tradeoff of, "do I=20 > send my location in the clear so I can progress the emergency=20 > call, or do I abandon the call if I can't protect my location=20 > privacy". I assume nearly all of us will choose the former,=20 > but, again, only after we try and fail to protect it. >=20 > The 1% is the special case, and instead of=20 > TLS-with-server-certs, they will do TLS-with-client-certs. >=20 > Brian >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Friday, September 01, 2006 10:29 AM > > To: Brian Rosen; Andrew Newton > > Cc: Ecrit@Ietf.Org > > Subject: RE: [Ecrit] Re: How many people do we plan to kill > >=20 > > Brian, > >=20 > > From the peanut gallery: > >=20 > > My impression just from reading this thread is that there are two=20 > > cases being considered: > >=20 > > 1) 90% - does not require any security, just requires an input to=20 > > result in some public information, > >=20 > > 2) 10% - requires security to protect some data from being=20 > given out=20 > > to a select group of people. > >=20 > > The solution proposed seems to focus first on catering to=20 > the 10%, and=20 > > telling the other 90% that if you jump through the hoops and it=20 > > doesn't work, try an alternate unprotected means. > >=20 > > That seems backwards to me. It seems like the 90% path should be=20 > > tried first, and if the data turns out to require a higher=20 > degree of=20 > > protection, the system challenges the requestor to authenticate=20 > > themselves and move to a confidential mode of exchanging the=20 > > information. > >=20 > > Is that the case? > >=20 > > Mike > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Friday, September 01, 2006 8:24 AM > > > To: 'Andrew Newton' > > > Cc: 'Ecrit@Ietf.Org' > > > Subject: RE: [Ecrit] Re: How many people do we plan to kill > > > > > > I agree that there is no off the shelf client library that=20 > > > automatically retries a failed TLS operation by=20 > attempting a plain=20 > > > TCP operation, but I think it's about 2 or 3 lines of=20 > code, in the=20 > > > application, to do it. > > > > > > The last paragraph is not the special case; it's the normal case. > > > The normal case is TLS with basic/digest so that the query gets=20 > > > privacy and integrity protection when sending its location and=20 > > > getting its emergency call URI. Its backup, if it needs to and=20 > > > wants to, is to try the operation again as a plain TCP=20 > query, with=20 > > > no protection. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Andrew Newton [mailto:andy@hxr.us] > > > > Sent: Friday, September 01, 2006 8:14 AM > > > > To: Brian Rosen > > > > Cc: 'Henning Schulzrinne'; 'Ecrit@Ietf.Org' > > > > Subject: Re: [Ecrit] Re: How many people do we plan to kill > > > > > > > > > > > > On Sep 1, 2006, at 7:33 AM, Brian Rosen wrote: > > > > > > > > > Andy > > > > > > > > > > I kept thinking I was missing something. At this point, > > > I think you > > > > > are missing something. > > > > > > > > > > The endpoint would first attempt to create a TLS=20 > connection. If=20 > > > > > that succeeded, then he would complete his "https" query. > > > > > > > > > > If it failed, he does an "http" query. > > > > > > > > > > All servers that I know of would support that. All > > > client libraries > > > > > that I know of would support that. > > > > > > > > Oh, I think I understand what you are saying. And no > > > client library > > > > that I know of supports this out of the box. The LoST=20 > application=20 > > > > will have to specifically employ this retry logic. > > > > > > > > > For the moment (maybe forever) ignore my special=20 > case; we need=20 > > > > > to make sure we agree on the basic mechanism before=20 > we deal with=20 > > > > > special cases. > > > > > > > > Is your special case the paragraph that follows? Because > > > I'll happily > > > > ignore it if it is not up for consideration. > > > > > > > > > The normal, should-work-every-time case is a TLS query > > > with basic/ > > > > > digest authentication. There is a backup, completely at > > > the option > > > > > of the client, to run a no-security query and get the > > > same response > > > > > it would have if the TLS attempt had succeeded. The > > > server doesn't > > > > > care if you use TLS, the client does. The TLS query is on a=20 > > > > > different port than the non-TLS query, as it is on=20 > any similar=20 > > > > > server. > > > > > > > > -andy > > > > > > > > > _______________________________________________ > > > 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 Sep 01 10:51:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJAMp-00013K-LQ; Fri, 01 Sep 2006 10:51:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJAMo-00013B-FH for ecrit@ietf.org; Fri, 01 Sep 2006 10:51:34 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJAMn-0000nW-5Y for ecrit@ietf.org; Fri, 01 Sep 2006 10:51:34 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k81EpQmx029049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Sep 2006 07:51:27 -0700 Received: from [10.0.1.2] (vpn-10-50-16-138.qualcomm.com [10.50.16.138]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k81EpOHp023603; Fri, 1 Sep 2006 07:51:25 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <066f01c6cdc1$7fa59ca0$640fa8c0@cis.neustar.com> References: <066f01c6cdc1$7fa59ca0$640fa8c0@cis.neustar.com> Date: Fri, 1 Sep 2006 07:51:21 -0700 To: "Brian Rosen" , "'Andrew Newton'" From: Ted Hardie Subject: RE: [Ecrit] Re: How many people do we plan to kill Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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: , Errors-To: ecrit-bounces@ietf.org At 8:23 AM -0400 9/1/06, Brian Rosen wrote: > >The last paragraph is not the special case; it's the normal case. >The normal case is TLS with basic/digest so that the query gets privacy and >integrity protection when sending its location and getting its emergency >call URI. Its backup, if it needs to and wants to, is to try the operation >again as a plain TCP query, with no protection. I believe that the normal case is TLS with server certificates, and that the use of a basic/digest authentication would *NOT* be layered on top of it, since there is no reason for the server to authenticate the client. In the use case where that authentication is needed, client certificates or digest could be used, but I don't think it is required for urn:service:sos lookups. If you re-use LoST for urn:service:emergency-infrastructure (as I mentioned yesterday), then maybe there it is. Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 01 10:57:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJARt-0003ID-8X; Fri, 01 Sep 2006 10:56:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJARr-0003I2-Qn for ecrit@ietf.org; Fri, 01 Sep 2006 10:56:47 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJARq-000144-CH for ecrit@ietf.org; Fri, 01 Sep 2006 10:56:47 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GJARk-0002uq-3L; Fri, 01 Sep 2006 09:56:40 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , "'Andrew Newton'" Subject: RE: [Ecrit] Re: How many people do we plan to kill Date: Fri, 1 Sep 2006 10:56:38 -0400 Message-ID: <06b701c6cdd6$d5907f30$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301E4E0E9@xmb-rtp-20b.amer.cisco.com> Thread-Index: AcbNwBqUaPn9ifAfSSOnvYX7Ezfp2gAAKTCwAARnW4AAAFX3AAAAWQuAAABgBTA= X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 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: , Errors-To: ecrit-bounces@ietf.org You understand. I confused you by talking about HTTP auth. My mistake, creating confusion. You don't need client auth in most cases. Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Friday, September 01, 2006 10:50 AM > To: Brian Rosen; Andrew Newton > Cc: Ecrit@Ietf.Org > Subject: RE: [Ecrit] Re: How many people do we plan to kill > > Brian, > > That sounds like a logical argument for integrity and confidentiality. > > So, the authentication aspects are secondary, correct? That is what > threw me. The authentication would only be required if the response > (jurisdicational data) for some reason was only to be given out to > select clients. Your comments earlier suggested that the authentication > would be done on all queries, and if that failed, then some fall-back > action taken. Did I misread you on that? > > Mike > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Friday, September 01, 2006 10:40 AM > > To: Michael Hammer (mhammer); 'Andrew Newton' > > Cc: 'Ecrit@Ietf.Org' > > Subject: RE: [Ecrit] Re: How many people do we plan to kill > > > > Nope. > > > > 99% of the queries will be from end devices that want privacy > > and integrity protection. They will query with > > TLS-with-server-certs. IF THAT FAILS, and only if it fails, > > will they fall back to no TLS, no security, just a raw TCP > > based query. It's unacceptable, I think, for anyone to be > > sending their location in the clear, unless they can't get a > > privacy service to work. > > Then, and only then, can they make the tradeoff of, "do I > > send my location in the clear so I can progress the emergency > > call, or do I abandon the call if I can't protect my location > > privacy". I assume nearly all of us will choose the former, > > but, again, only after we try and fail to protect it. > > > > The 1% is the special case, and instead of > > TLS-with-server-certs, they will do TLS-with-client-certs. > > > > Brian > > > > > -----Original Message----- > > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > > Sent: Friday, September 01, 2006 10:29 AM > > > To: Brian Rosen; Andrew Newton > > > Cc: Ecrit@Ietf.Org > > > Subject: RE: [Ecrit] Re: How many people do we plan to kill > > > > > > Brian, > > > > > > From the peanut gallery: > > > > > > My impression just from reading this thread is that there are two > > > cases being considered: > > > > > > 1) 90% - does not require any security, just requires an input to > > > result in some public information, > > > > > > 2) 10% - requires security to protect some data from being > > given out > > > to a select group of people. > > > > > > The solution proposed seems to focus first on catering to > > the 10%, and > > > telling the other 90% that if you jump through the hoops and it > > > doesn't work, try an alternate unprotected means. > > > > > > That seems backwards to me. It seems like the 90% path should be > > > tried first, and if the data turns out to require a higher > > degree of > > > protection, the system challenges the requestor to authenticate > > > themselves and move to a confidential mode of exchanging the > > > information. > > > > > > Is that the case? > > > > > > Mike > > > > > > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Friday, September 01, 2006 8:24 AM > > > > To: 'Andrew Newton' > > > > Cc: 'Ecrit@Ietf.Org' > > > > Subject: RE: [Ecrit] Re: How many people do we plan to kill > > > > > > > > I agree that there is no off the shelf client library that > > > > automatically retries a failed TLS operation by > > attempting a plain > > > > TCP operation, but I think it's about 2 or 3 lines of > > code, in the > > > > application, to do it. > > > > > > > > The last paragraph is not the special case; it's the normal case. > > > > The normal case is TLS with basic/digest so that the query gets > > > > privacy and integrity protection when sending its location and > > > > getting its emergency call URI. Its backup, if it needs to and > > > > wants to, is to try the operation again as a plain TCP > > query, with > > > > no protection. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Andrew Newton [mailto:andy@hxr.us] > > > > > Sent: Friday, September 01, 2006 8:14 AM > > > > > To: Brian Rosen > > > > > Cc: 'Henning Schulzrinne'; 'Ecrit@Ietf.Org' > > > > > Subject: Re: [Ecrit] Re: How many people do we plan to kill > > > > > > > > > > > > > > > On Sep 1, 2006, at 7:33 AM, Brian Rosen wrote: > > > > > > > > > > > Andy > > > > > > > > > > > > I kept thinking I was missing something. At this point, > > > > I think you > > > > > > are missing something. > > > > > > > > > > > > The endpoint would first attempt to create a TLS > > connection. If > > > > > > that succeeded, then he would complete his "https" query. > > > > > > > > > > > > If it failed, he does an "http" query. > > > > > > > > > > > > All servers that I know of would support that. All > > > > client libraries > > > > > > that I know of would support that. > > > > > > > > > > Oh, I think I understand what you are saying. And no > > > > client library > > > > > that I know of supports this out of the box. The LoST > > application > > > > > will have to specifically employ this retry logic. > > > > > > > > > > > For the moment (maybe forever) ignore my special > > case; we need > > > > > > to make sure we agree on the basic mechanism before > > we deal with > > > > > > special cases. > > > > > > > > > > Is your special case the paragraph that follows? Because > > > > I'll happily > > > > > ignore it if it is not up for consideration. > > > > > > > > > > > The normal, should-work-every-time case is a TLS query > > > > with basic/ > > > > > > digest authentication. There is a backup, completely at > > > > the option > > > > > > of the client, to run a no-security query and get the > > > > same response > > > > > > it would have if the TLS attempt had succeeded. The > > > > server doesn't > > > > > > care if you use TLS, the client does. The TLS query is on a > > > > > > different port than the non-TLS query, as it is on > > any similar > > > > > > server. > > > > > > > > > > -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 Fri Sep 01 11:03:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJAYU-0003Ww-7Z; Fri, 01 Sep 2006 11:03:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJAYT-0003UJ-16 for ecrit@ietf.org; Fri, 01 Sep 2006 11:03:37 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJAYS-0001Pl-IT for ecrit@ietf.org; Fri, 01 Sep 2006 11:03:37 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k81F3QDt022386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Sep 2006 08:03:26 -0700 Received: from [10.0.1.2] (vpn-10-50-16-138.qualcomm.com [10.50.16.138]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k81F3LUg027532; Fri, 1 Sep 2006 08:03:25 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <06b601c6cdd4$82658550$640fa8c0@cis.neustar.com> References: <06b601c6cdd4$82658550$640fa8c0@cis.neustar.com> Date: Fri, 1 Sep 2006 08:03:20 -0700 To: "Brian Rosen" , "'Michael Hammer \(mhammer\)'" , "'Andrew Newton'" From: Ted Hardie Subject: RE: [Ecrit] Re: How many people do we plan to kill Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 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: , Errors-To: ecrit-bounces@ietf.org At 10:39 AM -0400 9/1/06, Brian Rosen wrote: >Nope. > >99% of the queries will be from end devices that want privacy and integrity >protection. They will query with TLS-with-server-certs. IF THAT FAILS, and >only if it fails, will they fall back to no TLS, no security, just a raw TCP >based query. If I understand correctly, you actually mean over HTTP, not over a raw TCP transport. > It's unacceptable, I think, for anyone to be sending their >location in the clear, unless they can't get a privacy service to work. There actually are lots of devices that might trust the layer two encryption between their device and its first hop and their provider's network sufficiently that they would not bother with TLS. In any case, if you are supporting HTTP (or raw TCP) as a fallback, you have to support it on the server side, full stop, as there is no way of guaranteeing that the client using it has or has not tried tls and failed. >Then, and only then, can they make the tradeoff of, "do I send my location >in the clear so I can progress the emergency call, or do I abandon the call >if I can't protect my location privacy". I assume nearly all of us will >choose the former, but, again, only after we try and fail to protect it. There is an underlying question here of whether we need to design one protocol method for look-ups when the intent is store information for later use and a different protocol method for use when the information is needed during an emergency. In the first, the bias is for privacy; in the second, the bias is for minimizing latency. We've discussed this optimization before, and my sense is that we have a rough consensus that we push people away from starting from scratch during emergency call setup at the BCP level (encouraging the lookups to take place at times when locations have changed, on boot, and after expiry). I personally believe we also need to support a stripped-down, latency-optimized version for use during call set-up, for cases like booting the phone for the emergency call. Re-using that for cases where TLS fails makes sense to me, but there is an obvious attack here--insert a monkey in the middle that will fail the TLS check so that the client will drop down to a protocol where the monkey in the middle will succeed. Ted >The 1% is the special case, and instead of TLS-with-server-certs, they will >do TLS-with-client-certs. > >Brian > >> -----Original Message----- >> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] >> Sent: Friday, September 01, 2006 10:29 AM >> To: Brian Rosen; Andrew Newton >> Cc: Ecrit@Ietf.Org >> Subject: RE: [Ecrit] Re: How many people do we plan to kill >> >> Brian, >> >> From the peanut gallery: >> >> My impression just from reading this thread is that there are two cases >> being considered: >> >> 1) 90% - does not require any security, just requires an input to result >> in some public information, >> >> 2) 10% - requires security to protect some data from being given out to >> a select group of people. >> >> The solution proposed seems to focus first on catering to the 10%, and >> telling the other 90% that if you jump through the hoops and it doesn't >> work, try an alternate unprotected means. >> >> That seems backwards to me. It seems like the 90% path should be tried >> first, and if the data turns out to require a higher degree of >> protection, the system challenges the requestor to authenticate >> themselves and move to a confidential mode of exchanging the >> information. >> >> Is that the case? >> >> Mike >> >> >> >> > -----Original Message----- >> > From: Brian Rosen [mailto:br@brianrosen.net] >> > Sent: Friday, September 01, 2006 8:24 AM >> > To: 'Andrew Newton' >> > Cc: 'Ecrit@Ietf.Org' >> > Subject: RE: [Ecrit] Re: How many people do we plan to kill >> > >> > I agree that there is no off the shelf client library that > > > automatically retries a failed TLS operation by attempting a >> > plain TCP operation, but I think it's about 2 or 3 lines of >> > code, in the application, to do it. >> > >> > The last paragraph is not the special case; it's the normal case. >> > The normal case is TLS with basic/digest so that the query >> > gets privacy and integrity protection when sending its >> > location and getting its emergency call URI. Its backup, if >> > it needs to and wants to, is to try the operation again as a >> > plain TCP query, with no protection. >> > >> > Brian >> > >> > > -----Original Message----- >> > > From: Andrew Newton [mailto:andy@hxr.us] >> > > Sent: Friday, September 01, 2006 8:14 AM >> > > To: Brian Rosen >> > > Cc: 'Henning Schulzrinne'; 'Ecrit@Ietf.Org' >> > > Subject: Re: [Ecrit] Re: How many people do we plan to kill >> > > >> > > >> > > On Sep 1, 2006, at 7:33 AM, Brian Rosen wrote: >> > > >> > > > Andy >> > > > >> > > > I kept thinking I was missing something. At this point, >> > I think you >> > > > are missing something. >> > > > >> > > > The endpoint would first attempt to create a TLS connection. If >> > > > that succeeded, then he would complete his "https" query. >> > > > >> > > > If it failed, he does an "http" query. >> > > > >> > > > All servers that I know of would support that. All >> > client libraries >> > > > that I know of would support that. >> > > >> > > Oh, I think I understand what you are saying. And no >> > client library >> > > that I know of supports this out of the box. The LoST application >> > > will have to specifically employ this retry logic. >> > > >> > > > For the moment (maybe forever) ignore my special case; we need to >> > > > make sure we agree on the basic mechanism before we deal with >> > > > special cases. >> > > >> > > Is your special case the paragraph that follows? Because >> > I'll happily >> > > ignore it if it is not up for consideration. >> > > >> > > > The normal, should-work-every-time case is a TLS query >> > with basic/ >> > > > digest authentication. There is a backup, completely at >> > the option >> > > > of the client, to run a no-security query and get the >> > same response >> > > > it would have if the TLS attempt had succeeded. The >> > server doesn't >> > > > care if you use TLS, the client does. The TLS query is on a >> > > > different port than the non-TLS query, as it is on any similar >> > > > server. >> > > >> > > -andy >> > >> > >> > _______________________________________________ >> > Ecrit mailing list >> > Ecrit@ietf.org >> > https://www1.ietf.org/mailman/listinfo/ecrit >> > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 01 11:26:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJAuB-0008L5-JQ; Fri, 01 Sep 2006 11:26:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJAuA-0008Ij-8M for ecrit@ietf.org; Fri, 01 Sep 2006 11:26:02 -0400 Received: from moutng.kundenserver.de ([212.227.126.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJAu7-0003qG-SJ for ecrit@ietf.org; Fri, 01 Sep 2006 11:26:02 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1GJAu70Yy6-0008WH; Fri, 01 Sep 2006 17:25:59 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Fri, 01 Sep 2006 15:18:42 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1157123922.53.0.48328997426.issue13@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Provags-ID: kundenserver.de abuse@kundenserver.de login:518a04bce8f5fdb19ebc1cc661140948 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Ecrit] [issue13] XML Schema vs. Relax NG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: LoST Issue Tracker List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes Tschofenig added the comment: The pre -01 draft version contains the Relax NG schema.=20 http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/draft-ietf-ecrit-lost-0= 1=2Etxt ---------- status: chatting -> done-cbb __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 01 11:28:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJAwB-0001Of-Je; Fri, 01 Sep 2006 11:28:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJAwA-0001OU-TZ for ecrit@ietf.org; Fri, 01 Sep 2006 11:28:06 -0400 Received: from moutng.kundenserver.de ([212.227.126.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJAw8-000438-FU for ecrit@ietf.org; Fri, 01 Sep 2006 11:28:06 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1GJAw72gDh-0003oj; Fri, 01 Sep 2006 17:28:03 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Fri, 01 Sep 2006 15:20:47 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1157124047.25.0.365625077685.issue9@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Provags-ID: kundenserver.de abuse@kundenserver.de login:518a04bce8f5fdb19ebc1cc661140948 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Ecrit] [issue9] LoST Response with PSAP Preference X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: LoST Issue Tracker List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes Tschofenig added the comment: Roger decided to withdraw his proposal.=20 Issue closed. ---------- status: unread -> done-cbb __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 01 11:29:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJAxb-00027u-Kw; Fri, 01 Sep 2006 11:29:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJAxb-00027o-5V for ecrit@ietf.org; Fri, 01 Sep 2006 11:29:35 -0400 Received: from moutng.kundenserver.de ([212.227.126.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJAxX-0004EI-OA for ecrit@ietf.org; Fri, 01 Sep 2006 11:29:35 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1GJAxX10KS-0003PI; Fri, 01 Sep 2006 17:29:31 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Fri, 01 Sep 2006 15:22:14 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1157124134.83.0.868030567886.issue12@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Provags-ID: kundenserver.de abuse@kundenserver.de login:518a04bce8f5fdb19ebc1cc661140948 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Ecrit] [issue12] Validation Response X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: LoST Issue Tracker List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes Tschofenig added the comment: The pre -01 version has the compressed representation: See Section 6.7. (Validation Element) of http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/draft-ietf-ecrit-lost-0= 1=2Etxt ---------- status: chatting -> done-cbb __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 01 11:37:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJB57-0003GQ-St; Fri, 01 Sep 2006 11:37:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJB57-0003GL-0N for ecrit@ietf.org; Fri, 01 Sep 2006 11:37:21 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJB54-00059w-Li for ecrit@ietf.org; Fri, 01 Sep 2006 11:37:20 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GJB4r-0007AN-TO; Fri, 01 Sep 2006 10:37:06 -0500 From: "Brian Rosen" To: "'Ted Hardie'" , "'Michael Hammer \(mhammer\)'" , "'Andrew Newton'" Subject: RE: [Ecrit] Re: How many people do we plan to kill Date: Fri, 1 Sep 2006 11:37:00 -0400 Message-ID: <06ca01c6cddc$7b698550$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: Thread-Index: AcbN18Vk3P7GalhfRT+U7mdSk4uOhAAAGOsg X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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: , Errors-To: ecrit-bounces@ietf.org In line > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Friday, September 01, 2006 11:03 AM > To: Brian Rosen; 'Michael Hammer (mhammer)'; 'Andrew Newton' > Cc: 'Ecrit@Ietf.Org' > Subject: RE: [Ecrit] Re: How many people do we plan to kill > > At 10:39 AM -0400 9/1/06, Brian Rosen wrote: > >Nope. > > > >99% of the queries will be from end devices that want privacy and > integrity > >protection. They will query with TLS-with-server-certs. IF THAT FAILS, > and > >only if it fails, will they fall back to no TLS, no security, just a raw > TCP > >based query. > > If I understand correctly, you actually mean over HTTP, not over > a raw TCP transport. Yeah, I was half-heartedly dealing with the issue that so far, LoST doesn't actually specify a protocol, even though we are all thinking some form of http transport. It's http with TLS and http without TLS. > > > It's unacceptable, I think, for anyone to be sending their > >location in the clear, unless they can't get a privacy service to work. > > There actually are lots of devices that might trust the layer two > encryption between their device and its first hop and their provider's > network sufficiently that they would not bother with TLS. In any case, > if you are supporting HTTP (or raw TCP) as a fallback, you have > to support it on the server side, full stop, as there is no way of > guaranteeing that the client using it has or has not tried tls and failed. I agree, all servers have to support HTTP. It's not a problem for them (they aren't giving out sensitive data). > > > >Then, and only then, can they make the tradeoff of, "do I send my > location > >in the clear so I can progress the emergency call, or do I abandon the > call > >if I can't protect my location privacy". I assume nearly all of us will > >choose the former, but, again, only after we try and fail to protect it. > > There is an underlying question here of whether we need to design > one protocol method for look-ups when the intent is store information > for later use and a different protocol method for use when the > information is needed during an emergency. In the first, the bias > is for privacy; in the second, the bias is for minimizing latency. Yeah, we should look at that. Nothing strikes me as an obvious way to differentiate. Even in an emergency, you WANT privacy, it's just that you are willing to sacrifice it if necessary. > > We've discussed this optimization before, and my sense is that we > have a rough consensus that we push people away from starting > from scratch during emergency call setup at the BCP level (encouraging > the lookups to take place at times when locations have changed, on > boot, and after expiry). I personally believe we also need to support > a stripped-down, latency-optimized version for use during call set-up, > for cases like booting the phone for the emergency call. Re-using that > for cases where TLS fails makes sense to me, but there is an obvious > attack here--insert a monkey in the middle that will fail the TLS > check so that the client will drop down to a protocol where the > monkey in the middle will succeed. Agree that having a cached good PSAP URI is important. I would LIKE to have the LoST query run at call time always. The reason is that during disasters, things change. Even with a still-valid TTL, it really is better to query and get the current data. Can't count on that though, because, it's in disasters that the queries are more likely to fail. MITM worries me also. We need to explore that area. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 01 11:40:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJB7t-0004cK-NZ; Fri, 01 Sep 2006 11:40:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJB7r-0004cC-N1 for ecrit@ietf.org; Fri, 01 Sep 2006 11:40:12 -0400 Received: from moutng.kundenserver.de ([212.227.126.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJB7q-0005Re-9n for ecrit@ietf.org; Fri, 01 Sep 2006 11:40:11 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1GJB7p3VZw-0008Tn; Fri, 01 Sep 2006 17:40:09 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Fri, 01 Sep 2006 15:32:53 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1157124773.42.0.519489447976.issue4@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Provags-ID: kundenserver.de abuse@kundenserver.de login:518a04bce8f5fdb19ebc1cc661140948 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Ecrit] [issue4] Service URN in Response Message X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: LoST Issue Tracker List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes Tschofenig added the comment: The pre -01 version of the draft carries optional element in the=20 response message. See Section 6.3 of http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/draft-ietf-ecrit-lost-0= 1=2Etxt ---------- status: chatting -> done-cbb __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 01 11:54:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJBLg-0001Z6-JP; Fri, 01 Sep 2006 11:54:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJBLf-0001Z1-Kx for ecrit@ietf.org; Fri, 01 Sep 2006 11:54:27 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ9yA-0007nq-9z for ecrit@ietf.org; Fri, 01 Sep 2006 10:26:06 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GJ9cx-0002bp-Cr for ecrit@ietf.org; Fri, 01 Sep 2006 10:04:15 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GJ9cr-0006wY-AD; Fri, 01 Sep 2006 09:04:05 -0500 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: [Ecrit] Re: How many people do we plan to kill Date: Fri, 1 Sep 2006 10:04:03 -0400 Message-ID: <06a001c6cdcf$7d36b720$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: Thread-Index: AcbNzteN01WcUjfFRSWeUeosS+HuYwAAHm8A X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: -2.5 (--) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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: , Errors-To: ecrit-bounces@ietf.org To establish a security association that the client reasonably trusts the server. The server will always trust the client. You then need to create a shared secret to use for the privacy key based on the SA. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Friday, September 01, 2006 9:59 AM > To: Brian Rosen > Cc: 'Henning Schulzrinne'; 'Ecrit@Ietf.Org' > Subject: Re: [Ecrit] Re: How many people do we plan to kill > > > On Sep 1, 2006, at 8:23 AM, Brian Rosen wrote: > > > I agree that there is no off the shelf client library that > > automatically > > retries a failed TLS operation by attempting a plain TCP operation, > > but I > > think it's about 2 or 3 lines of code, in the application, to do it. > > > > The last paragraph is not the special case; it's the normal case. > > The normal case is TLS with basic/digest so that the query gets > > privacy and > > integrity protection when sending its location and getting its > > emergency > > call URI. Its backup, if it needs to and wants to, is to try the > > operation > > again as a plain TCP query, with no protection. > > Ignoring the TLS part for a second, just why is HTTP basic or digest > authentication necessary? > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 01 14:45:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJE0s-0001L8-72; Fri, 01 Sep 2006 14:45:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJE0q-0001L0-EF; Fri, 01 Sep 2006 14:45:08 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJE0p-0002Os-3K; Fri, 01 Sep 2006 14:45:08 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GJE0f-0001nb-8X; Fri, 01 Sep 2006 13:44:57 -0500 From: "Brian Rosen" To: "'GEOPRIV'" , "'Ecrit@Ietf.Org'" Date: Fri, 1 Sep 2006 14:44:59 -0400 Message-ID: <073201c6cdf6$bce4adb0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0733_01C6CDD5.35D30DB0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbNN2ni6DSEKWv4QG6zY2iLRkoRxwAvteOA X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: Subject: [Ecrit] FW: I-D ACTION:draft-ietf-sip-location-conveyance-04.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: , Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0733_01C6CDD5.35D30DB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Note that we have released a new version of location conveyance. This edition has some significant changes and rewrites. Your comments would be appreciated. -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Thursday, August 31, 2006 3:50 PM To: i-d-announce@ietf.org Cc: sip@ietf.org Subject: I-D ACTION:draft-ietf-sip-location-conveyance-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Session Initiation Protocol Location Conveyance Author(s) : J. Polk, B. Rosen Filename : draft-ietf-sip-location-conveyance-04.txt Pages : 27 Date : 2006-8-31 This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The extension covers end to end conveyance as well as location-based routing, where proxy servers make routing decisions based on the location of the UAC. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-04.tx t To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-location-conveyance-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-location-conveyance-04.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_0733_01C6CDD5.35D30DB0 Content-Type: Message/External-body; name="ATT01296.dat" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT01296.dat" Content-Type: text/plain Content-ID: <2006-8-31105138.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-location-conveyance-04.txt ------=_NextPart_000_0733_01C6CDD5.35D30DB0 Content-Type: Message/External-body; name="draft-ietf-sip-location-conveyance-04.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-sip-location-conveyance-04.txt" Content-Type: text/plain Content-ID: <2006-8-31105138.I-D@ietf.org> ------=_NextPart_000_0733_01C6CDD5.35D30DB0 Content-Type: text/plain; name="ATT01299.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT01299.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------=_NextPart_000_0733_01C6CDD5.35D30DB0 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_0733_01C6CDD5.35D30DB0-- From ecrit-bounces@ietf.org Fri Sep 01 15:08:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJEMy-0002Ll-T2; Fri, 01 Sep 2006 15:08:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJEMx-0002LQ-MT; Fri, 01 Sep 2006 15:07:59 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJEMu-0003cm-2C; Fri, 01 Sep 2006 15:07:59 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 01 Sep 2006 12:07:55 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k81J7tYR013647; Fri, 1 Sep 2006 12:07:55 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k81J7t1E009745; Fri, 1 Sep 2006 12:07:55 -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.1830); Fri, 1 Sep 2006 12:07:55 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.89.71]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Sep 2006 12:07:54 -0700 Message-Id: <4.3.2.7.2.20060901135912.0368bbf0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 01 Sep 2006 14:07:53 -0500 To: "'GEOPRIV'" , "'Ecrit@Ietf.Org'" From: "James M. Polk" In-Reply-To: <073201c6cdf6$bce4adb0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 01 Sep 2006 19:07:54.0885 (UTC) FILETIME=[EDEBEB50:01C6CDF9] DKIM-Signature: a=rsa-sha1; q=dns; l=4909; t=1157137675; x=1158001675; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:draft-ietf-sip-location-conveyance-04.txt=20; X=v=3Dcisco.com=3B=20h=3DNipG362oGES9fSFsrOiAHLInSUs=3D; b=HobKlfx1vUJ8RKvYo5OnXfvN6VwFaGOnppkjVMwUgLv2cf//i910PPZcoihoHl6LqkVpT2S9 mH0og+aHdjDMk4UKkpDAz5erXlWz8bjEAotffpTMduHf8Se9C+Gqo9zO; Authentication-Results: sj-dkim-3.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: Subject: [Ecrit] draft-ietf-sip-location-conveyance-04.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: , Errors-To: ecrit-bounces@ietf.org Here is a highlevel list of the changes that have been made from the SIP WG version -03 to this version -04: - removed the inappropriate 2119 language from the Requirements section (which is now an appendix in the back, but will stay in the final version as a point of history of the doc) - removed the old Section 2., which was a "Location in a header vs. in a body" artifact from the original versions of the document. That subject is no longer current. - Added a new Geopriv (or Privacy) Considerations section, and interwove critical to know Geopriv points into the Intro - Changed the ABNF to reflect discussion on how restrictive the location-by-reference schemes should be, with an added "Editor's Note" discussing the issues being faced on this point. - Changed the "Location" header and option-tag to "Geolocation" header and option-tag, due to it being pointed out that there is a conflicting HTTP header called "Location". - Added a new element to PIDF-LO 'routing-query-allowed', which will "update" RFC 4119 - Stipulated the Reason Header can be used in the 424 Response Message. This is allowed in 3326, but not normally how Reason is used. - added SUBSCRIBE and NOTIFY as Methods for location conveyance when used to dereference a sip:, sips: or pres: location-by-reference URI - Added OPTIONS Method for a UAC to request the location of a UAS with a Require header geolocation option-tag. At 02:44 PM 9/1/2006 -0400, Brian Rosen wrote: >Note that we have released a new version of location conveyance. > >This edition has some significant changes and rewrites. Your comments would >be appreciated. > >-----Original Message----- >From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >Sent: Thursday, August 31, 2006 3:50 PM >To: i-d-announce@ietf.org >Cc: sip@ietf.org >Subject: I-D ACTION:draft-ietf-sip-location-conveyance-04.txt > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Session Initiation Protocol Working Group >of the IETF. > > Title : Session Initiation Protocol Location Conveyance > Author(s) : J. Polk, B. Rosen > Filename : draft-ietf-sip-location-conveyance-04.txt > Pages : 27 > Date : 2006-8-31 > >This document defines an extension to the Session Initiation > Protocol (SIP) to convey geographic location information from one > SIP entity to another SIP entity. The extension covers end to end > conveyance as well as location-based routing, where proxy servers > make routing decisions based on the location of the UAC. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-04.tx >t > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of >the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > >Internet-Drafts are also available by anonymous FTP. Login with the >username "anonymous" and a password of your e-mail address. After >logging in, type "cd internet-drafts" and then >"get draft-ietf-sip-location-conveyance-04.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-sip-location-conveyance-04.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: <2006-8-31105138.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-sip-location-conveyance-04.txt >Content-Type: text/plain >Content-ID: <2006-8-31105138.I-D@ietf.org> > > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 01 16:25:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJFZn-0003lo-2N; Fri, 01 Sep 2006 16:25:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJFZm-0003li-9Q for ecrit@ietf.org; Fri, 01 Sep 2006 16:25:18 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJFZl-0000MR-3X for ecrit@ietf.org; Fri, 01 Sep 2006 16:25:18 -0400 Received: from [10.0.1.50] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Fri, 01 Sep 2006 16:25:06 -0400 id 0158841C.44F89729.000027A8 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "Ecrit@Ietf.Org" From: Andrew Newton Date: Fri, 1 Sep 2006 16:25:16 -0400 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.5 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Ecrit] faux security 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: , Errors-To: ecrit-bounces@ietf.org As I stated before, I do not hold myself out as a security expert. However, it doesn't take much of a security expert to identify the security issue with the try-with-TLS-then-retry-without concept. If an attacker wants to get the location data, they do not have to compromise the TLS session. All they have to do is scuttle the TLS session. That's easily enough done: interfere with the packets, randomly twiddling bits. Once the client gives up on the TLS session, it will drop back to naked TCP, at which point the attacker just has to listen and they will receive the location information. This sounds even easier than the classic SSL/TLS downgrade attack. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 01 16:25:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJFZh-0003lP-TY; Fri, 01 Sep 2006 16:25:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJFZg-0003lA-MR for ecrit@ietf.org; Fri, 01 Sep 2006 16:25:12 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJFZe-0000MR-EC for ecrit@ietf.org; Fri, 01 Sep 2006 16:25:12 -0400 Received: from [10.0.1.50] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Fri, 01 Sep 2006 16:25:06 -0400 id 0158841C.44F89722.000027A7 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <97337D91-63CF-477A-BC45-82210F3ACD8C@hxr.us> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "Ecrit@Ietf.Org" From: Andrew Newton Date: Fri, 1 Sep 2006 16:25:09 -0400 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.5 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [Ecrit] faux scalability 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: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "Ecrit@Ietf.Org" From: Andrew Newton Date: Fri, 1 Sep 2006 16:25:16 -0400 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.5 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Ecrit] faux security 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: , Errors-To: ecrit-bounces@ietf.org As I stated before, I do not hold myself out as a security expert. However, it doesn't take much of a security expert to identify the security issue with the try-with-TLS-then-retry-without concept. If an attacker wants to get the location data, they do not have to compromise the TLS session. All they have to do is scuttle the TLS session. That's easily enough done: interfere with the packets, randomly twiddling bits. Once the client gives up on the TLS session, it will drop back to naked TCP, at which point the attacker just has to listen and they will receive the location information. This sounds even easier than the classic SSL/TLS downgrade attack. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 01 16:25:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJFZh-0003lP-TY; Fri, 01 Sep 2006 16:25:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJFZg-0003lA-MR for ecrit@ietf.org; Fri, 01 Sep 2006 16:25:12 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJFZe-0000MR-EC for ecrit@ietf.org; Fri, 01 Sep 2006 16:25:12 -0400 Received: from [10.0.1.50] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Fri, 01 Sep 2006 16:25:06 -0400 id 0158841C.44F89722.000027A7 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <97337D91-63CF-477A-BC45-82210F3ACD8C@hxr.us> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "Ecrit@Ietf.Org" From: Andrew Newton Date: Fri, 1 Sep 2006 16:25:09 -0400 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.5 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [Ecrit] faux scalability 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: , Errors-To: ecrit-bounces@ietf.org This entire effort got started back when Brian proposed a solution using DNS. He picked DNS because it is very well known that DNS scales. Got into any reputable outfit dealing with scale of any magnitude and you'll notice that they will have many web farms, clustered 4 or 8 ways but perhaps only 2 DNS servers (and they'll readily admit that the second is not for load but for fail-over). Of course, there are exceptions, but generally this is true. DNS scales primarily for two reasons: it makes heavy use of caching and it consumes as few resources server-side as possible. That second aspect is primarily due to the fact that DNS is almost always done over UDP. Only the special exceptions default to TCP, such as zone transfers... which is typically an administrative function. Very apropos for this conversation. By definition, a TCP connection is at least 3 times slower to setup than a UDP datagram because of the TCP handshake. This is not to argue against TCP itself, as TCP has its advanges, but offered for illustrative purposes. TLS, which sits on top of TCP, has its own handshake, which I believe constitutes another 4 round trips... so at the very least 7 times slower when not including crypto overhead than if we just sent the message over UDP. Of course, crypto overhead is computationally expensive, so it isn't a null operation. And of course, I'd be remiss to point out that we haven't even sent the query to the server at this point. Finally, any HTTP authentication on top of that is one more roundtrip. The suggestion to retry without TSL when TLS fails brings this up to 11 times more packets and 11 times more latency than the original, scalable proposal. I think it is easy to see how this will not scale any where near as efficiently as DNS. Now consider what a LoST resolver must do. It accepts connections from LoST seekers on one end and establishes connections with LoST authoritative servers on the other end. A server only has a finite number of TCP connections it can handle, and for a LoST resolver with a standard tiered architecture, some of those are used up with the database connection pool, management ports, etc... When the server has reached the limit of the number of connections it can accept, in coming requests have to wait for previous requests to finish. The longer the resolver is held up retrying connections while hunting down answers, the longer requests wait. Consider a LoST seeker in Austria resolving a location for a UA in New York. 11 packets to setup the connection to the Austrian LoST forrest guide, 11 packets when redirect to the US LoST forrest guide, 11 packets when redirected to the New York state forrest guide, and 11 packets to connect to the New York authoritative server. 44 more packets needed than the original idea. This is not a solution with that is considerate of scalability. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit it>, Errors-To: ecrit-bounces@ietf.org This entire effort got started back when Brian proposed a solution using DNS. He picked DNS because it is very well known that DNS scales. Got into any reputable outfit dealing with scale of any magnitude and you'll notice that they will have many web farms, clustered 4 or 8 ways but perhaps only 2 DNS servers (and they'll readily admit that the second is not for load but for fail-over). Of course, there are exceptions, but generally this is true. DNS scales primarily for two reasons: it makes heavy use of caching and it consumes as few resources server-side as possible. That second aspect is primarily due to the fact that DNS is almost always done over UDP. Only the special exceptions default to TCP, such as zone transfers... which is typically an administrative function. Very apropos for this conversation. By definition, a TCP connection is at least 3 times slower to setup than a UDP datagram because of the TCP handshake. This is not to argue against TCP itself, as TCP has its advanges, but offered for illustrative purposes. TLS, which sits on top of TCP, has its own handshake, which I believe constitutes another 4 round trips... so at the very least 7 times slower when not including crypto overhead than if we just sent the message over UDP. Of course, crypto overhead is computationally expensive, so it isn't a null operation. And of course, I'd be remiss to point out that we haven't even sent the query to the server at this point. Finally, any HTTP authentication on top of that is one more roundtrip. The suggestion to retry without TSL when TLS fails brings this up to 11 times more packets and 11 times more latency than the original, scalable proposal. I think it is easy to see how this will not scale any where near as efficiently as DNS. Now consider what a LoST resolver must do. It accepts connections from LoST seekers on one end and establishes connections with LoST authoritative servers on the other end. A server only has a finite number of TCP connections it can handle, and for a LoST resolver with a standard tiered architecture, some of those are used up with the database connection pool, management ports, etc... When the server has reached the limit of the number of connections it can accept, in coming requests have to wait for previous requests to finish. The longer the resolver is held up retrying connections while hunting down answers, the longer requests wait. Consider a LoST seeker in Austria resolving a location for a UA in New York. 11 packets to setup the connection to the Austrian LoST forrest guide, 11 packets when redirect to the US LoST forrest guide, 11 packets when redirected to the New York state forrest guide, and 11 packets to connect to the New York authoritative server. 44 more packets needed than the original idea. This is not a solution with that is considerate of scalability. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 01 16:25:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJFZw-0003nX-82; Fri, 01 Sep 2006 16:25:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJFZu-0003ml-Qr for ecrit@ietf.org; Fri, 01 Sep 2006 16:25:26 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJFZt-0000MR-LQ for ecrit@ietf.org; Fri, 01 Sep 2006 16:25:26 -0400 Received: from [10.0.1.50] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Fri, 01 Sep 2006 16:25:13 -0400 id 01588421.44F89731.000027BF Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <41A221BF-FD55-462B-A219-DB17F02F6CD6@hxr.us> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "Ecrit@Ietf.Org" From: Andrew Newton Date: Fri, 1 Sep 2006 16:25:25 -0400 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.5 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Ecrit] faux privacy concerns 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: , Errors-To: ecrit-bounces@ietf.org One of the reasons given for needing to do the try-with-TLS-then- retry-without scheme is that of privacy concerns. However, as James Winterbottom stated, LoST does not transmit any identity information. If an attacker can eaves drop on a LoST session, all they get is location information. They do not get any user identity to associate to that location information. Given that the try-with-TLS-then-retry-without scheme has serious consequences regarding the scalability of the LoST system and offers a security model that is easily foiled for a benefit that is of limited value, this scheme should not be considered. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 01 16:31:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJFfg-0008WS-AA; Fri, 01 Sep 2006 16:31:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJFff-0008Ur-BT for ecrit@ietf.org; Fri, 01 Sep 2006 16:31:23 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJFfZ-0000qM-Rg for ecrit@ietf.org; Fri, 01 Sep 2006 16:31:23 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 01 Sep 2006 13:31:17 -0700 X-IronPort-AV: i="4.08,201,1154934000"; d="scan'208"; a="316985994:sNHT29811854" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k81KVHRk026989; Fri, 1 Sep 2006 13:31:17 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k81KVH6Y017886; Fri, 1 Sep 2006 13:31:17 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Sep 2006 13:31:16 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Sep 2006 13:31:16 -0700 From: "Marc Linsner" To: "'Andrew Newton'" , "'Ecrit@Ietf.Org'" Subject: RE: [Ecrit] faux privacy concerns Date: Fri, 1 Sep 2006 16:31:14 -0400 Message-ID: <00ea01c6ce05$9263cc10$2a0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <41A221BF-FD55-462B-A219-DB17F02F6CD6@hxr.us> thread-index: AcbOBNjaUkT+vhKlT2K33AVoNtuagQAAD1Eg X-OriginalArrivalTime: 01 Sep 2006 20:31:16.0422 (UTC) FILETIME=[9311E660:01C6CE05] DKIM-Signature: a=rsa-sha1; q=dns; l=517; t=1157142677; x=1158006677; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=22Marc=20Linsner=22=20 |Subject:RE=3A=20[Ecrit]=20faux=20privacy=20concerns; X=v=3Dcisco.com=3B=20h=3D3fFww8iL7skGLSFuw0YnBVS63O0=3D; b=Z5ZE+3lJKoECxuNPNQrCcfocI1V+qDzhkjn+bWYVHOEqEHPBO0VH0nTPOC99cnW/iu7a1DPV VXjjBwvYoXEES9sRUduEk9zwfscJI1d77Y6VtW8FgiO3eZt1CDsuEZLK; Authentication-Results: sj-dkim-7.cisco.com; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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: , Errors-To: ecrit-bounces@ietf.org > > One of the reasons given for needing to do the > try-with-TLS-then- retry-without scheme is that of privacy > concerns. However, as James Winterbottom stated, LoST does > not transmit any identity information. If an attacker can > eaves drop on a LoST session, all they get is location > information. They do not get any user identity to associate > to that location information. But, it does reveal that an emergency of some kind *could be* happening at a the exposed location. -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 01 16:38:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJFmP-0004yD-69; Fri, 01 Sep 2006 16:38:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJFmN-0004vT-Oz for ecrit@ietf.org; Fri, 01 Sep 2006 16:38:19 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJFmM-0001Ew-G3 for ecrit@ietf.org; Fri, 01 Sep 2006 16:38:19 -0400 Received: from lion.cs.columbia.edu (IDENT:FElQip0pJ4HmmWhNgPfeM+7XjKCbNqEy@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k81KcDGb027028 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 1 Sep 2006 16:38:14 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k81KcDg7009527 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 1 Sep 2006 16:38:13 -0400 Message-ID: <44F89A30.9030601@cs.columbia.edu> Date: Fri, 01 Sep 2006 16:38:08 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Marc Linsner Subject: Re: [Ecrit] faux privacy concerns References: <00ea01c6ce05$9263cc10$2a0d0d0a@amer.cisco.com> In-Reply-To: <00ea01c6ce05$9263cc10$2a0d0d0a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter1.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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: , Errors-To: ecrit-bounces@ietf.org Plus, if you can intercept other streams, you might be able to guess pretty well. For example, if somebody uses SMTP, POP or IMAP, you can relate the IP addresses and get a location/userid mapping. Once you have an email address, Google gives you the name. See the recent AOL search query debacle for related work... That said, I think it is a lower-order privacy breach, particularly as many of these identify-revealing protocols are now being encrypted themselves. Marc Linsner wrote: >> One of the reasons given for needing to do the >> try-with-TLS-then- retry-without scheme is that of privacy >> concerns. However, as James Winterbottom stated, LoST does >> not transmit any identity information. If an attacker can >> eaves drop on a LoST session, all they get is location >> information. They do not get any user identity to associate >> to that location information. > > But, it does reveal that an emergency of some kind *could be* happening at a > the exposed location. > > -Marc- > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 01 16:41:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJFp0-00088M-1V; Fri, 01 Sep 2006 16:41:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJFoy-00085R-Mb for ecrit@ietf.org; Fri, 01 Sep 2006 16:41:00 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJFox-0001O4-EY for ecrit@ietf.org; Fri, 01 Sep 2006 16:41:00 -0400 Received: from [10.0.1.50] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Fri, 01 Sep 2006 16:40:55 -0400 id 01588421.44F89AD7.00002A60 In-Reply-To: <00ea01c6ce05$9263cc10$2a0d0d0a@amer.cisco.com> References: <00ea01c6ce05$9263cc10$2a0d0d0a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1A722585-A429-4856-8C54-D52E2F31FA4E@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] faux privacy concerns Date: Fri, 1 Sep 2006 16:40:58 -0400 To: "Marc Linsner" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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: , Errors-To: ecrit-bounces@ietf.org On Sep 1, 2006, at 4:31 PM, Marc Linsner wrote: > But, it does reveal that an emergency of some kind *could be* > happening at a > the exposed location. Given that an attacker could also listen in on the RTP stream and hear the caller give the location to the PSAP when asked to verify, this is not that big of a concern... especially for the trade-off of much more overhead for crappy security. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 01 17:13:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJGKK-0001K4-Uh; Fri, 01 Sep 2006 17:13:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJGKK-0001Jz-2R for ecrit@ietf.org; Fri, 01 Sep 2006 17:13:24 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJGKI-0003YW-On for ecrit@ietf.org; Fri, 01 Sep 2006 17:13:24 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 01 Sep 2006 14:13:22 -0700 X-IronPort-AV: i="4.08,201,1154934000"; d="scan'208"; a="1851738157:sNHT31053076" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k81LDLMW009628; Fri, 1 Sep 2006 14:13:21 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k81LDLw7024969; Fri, 1 Sep 2006 14:13:21 -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.1830); Fri, 1 Sep 2006 14:13:21 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Sep 2006 14:13:18 -0700 From: "Marc Linsner" To: "'Andrew Newton'" Subject: RE: [Ecrit] faux privacy concerns Date: Fri, 1 Sep 2006 17:13:16 -0400 Message-ID: <00f301c6ce0b$7346cde0$2a0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <1A722585-A429-4856-8C54-D52E2F31FA4E@hxr.us> thread-index: AcbOBvMUjI/A6vblSv29gs1y5C5UeQAA47/w X-OriginalArrivalTime: 01 Sep 2006 21:13:21.0202 (UTC) FILETIME=[73F4C120:01C6CE0B] DKIM-Signature: a=rsa-sha1; q=dns; l=939; t=1157145202; x=1158009202; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=22Marc=20Linsner=22=20 |Subject:RE=3A=20[Ecrit]=20faux=20privacy=20concerns; X=v=3Dcisco.com=3B=20h=3D3fFww8iL7skGLSFuw0YnBVS63O0=3D; b=rKBSUc9d38ua7/V64Zwn/GV79qmAm2RddjWnUQVBImKNkwdoUsOp9rUIIQ6DiWxdVqT4I61R lzbrNEb4sR0nwr9RLwSFk1xsEoAorYYK6w5i+xdGvC99IJwvmd1FI+up; Authentication-Results: sj-dkim-8.cisco.com; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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: , Errors-To: ecrit-bounces@ietf.org > > On Sep 1, 2006, at 4:31 PM, Marc Linsner wrote: > > But, it does reveal that an emergency of some kind *could be* > > happening at a the exposed location. > > Given that an attacker could also listen in on the RTP stream > and hear the caller give the location to the PSAP when asked > to verify, this is not that big of a concern... especially > for the trade-off of much more overhead for crappy security. > > -andy Now you're listening, before you were messing with packets...different paradigm, I think. Listening to TLS LoST query gains you nothing. Not the expert, but listening appears easier than messing with packets. Again, not the expert, but I heard the marketing. TLS LoST queries: 1) The querier knows if the data has been messed with. 2) A chance that an after-the-fact audit will reveal whether the responding LoST server is a real one. True? Does the benefit outweigh the effort? -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 01 17:32:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJGcM-0008P5-M6; Fri, 01 Sep 2006 17:32:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJGcL-0008Oz-EH for ecrit@ietf.org; Fri, 01 Sep 2006 17:32:01 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJGcK-0004m7-7n for ecrit@ietf.org; Fri, 01 Sep 2006 17:32:01 -0400 Received: from [10.0.1.50] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Fri, 01 Sep 2006 17:31:50 -0400 id 0158842E.44F8A6C6.000031EB In-Reply-To: <00f301c6ce0b$7346cde0$2a0d0d0a@amer.cisco.com> References: <00f301c6ce0b$7346cde0$2a0d0d0a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7FC33513-6FD6-467E-8F3F-8DFE102C8F9E@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] faux privacy concerns Date: Fri, 1 Sep 2006 17:31:52 -0400 To: Marc Linsner X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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: , Errors-To: ecrit-bounces@ietf.org On Sep 1, 2006, at 5:13 PM, Marc Linsner wrote: > Now you're listening, before you were messing with packets...different > paradigm, I think. Listening to TLS LoST query gains you nothing. > Not the > expert, but listening appears easier than messing with packets. Yes, but it doesn't take much more. After all, script kiddies have the tools at hand to synthesize packets. > Again, not the expert, but I heard the marketing. TLS LoST queries: > > 1) The querier knows if the data has been messed with. > 2) A chance that an after-the-fact audit will reveal whether the > responding > LoST server is a real one. Actually, the querier probably just knows that TLS didn't work and that they dropped back. Unless they are doing active intrusion detection, they probably don't know somebody messed with their stuff. A scheme that is an order of magnitude more chatty and latent without useful security is likely to be of little comfort to those doing a postmortem (in some cases, literally). > True? > Does the benefit outweigh the effort? Absolutely not. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 01 17:40:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJGkS-0005jw-Lm; Fri, 01 Sep 2006 17:40:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJGkR-0005jr-IB for ecrit@ietf.org; Fri, 01 Sep 2006 17:40:23 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJGkP-0005BU-7r for ecrit@ietf.org; Fri, 01 Sep 2006 17:40:23 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 01 Sep 2006 14:40:20 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k81LeKkw017627; Fri, 1 Sep 2006 14:40:20 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k81LeK1E003677; Fri, 1 Sep 2006 14:40:20 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Sep 2006 14:40:20 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Sep 2006 14:40:20 -0700 From: "Marc Linsner" To: "'Andrew Newton'" Subject: RE: [Ecrit] faux privacy concerns Date: Fri, 1 Sep 2006 17:40:17 -0400 Message-ID: <010701c6ce0f$384dc550$2a0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <7FC33513-6FD6-467E-8F3F-8DFE102C8F9E@hxr.us> thread-index: AcbODg0GKz3Y+MpeSFuSa11QPb4pfgAAQZqg X-OriginalArrivalTime: 01 Sep 2006 21:40:20.0225 (UTC) FILETIME=[38F80F10:01C6CE0F] DKIM-Signature: a=rsa-sha1; q=dns; l=1270; t=1157146820; x=1158010820; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=22Marc=20Linsner=22=20 |Subject:RE=3A=20[Ecrit]=20faux=20privacy=20concerns; X=v=3Dcisco.com=3B=20h=3D3fFww8iL7skGLSFuw0YnBVS63O0=3D; b=e1ImhRlefAIU71q57uyRLfALFR5Xr86h1aeU12qmGEXtDzS3NUFKuruDPI0BNDmMQGwEOUM+ 5vYubaL+lQjLSIAsm33tOxI+2TYxw9+0RUAAHwsWZ6mKPNK9mNGcbpW+; Authentication-Results: sj-dkim-3.cisco.com; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com verified; ); 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: , Errors-To: ecrit-bounces@ietf.org > On Sep 1, 2006, at 5:13 PM, Marc Linsner wrote: > > Now you're listening, before you were messing with > packets...different > > paradigm, I think. Listening to TLS LoST query gains you > nothing. > > Not the > > expert, but listening appears easier than messing with packets. > > Yes, but it doesn't take much more. After all, script > kiddies have the tools at hand to synthesize packets. > > > Again, not the expert, but I heard the marketing. TLS LoST queries: > > > > 1) The querier knows if the data has been messed with. > > 2) A chance that an after-the-fact audit will reveal whether the > > responding LoST server is a real one. > > Actually, the querier probably just knows that TLS didn't > work and that they dropped back. Unless they are doing > active intrusion detection, they probably don't know somebody > messed with their stuff. A scheme that is an order of > magnitude more chatty and latent without useful security is > likely to be of little comfort to those doing a postmortem > (in some cases, literally). You certainly add a level of comfort to on-line banking applications! :^) -Marc- > > True? > > Does the benefit outweigh the effort? > > Absolutely not. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Sep 02 05:42:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJS0O-0002zw-CX; Sat, 02 Sep 2006 05:41:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJS0N-0002zk-HK for ecrit@ietf.org; Sat, 02 Sep 2006 05:41:35 -0400 Received: from moutng.kundenserver.de ([212.227.126.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJS0M-0001HX-4O for ecrit@ietf.org; Sat, 02 Sep 2006 05:41:35 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis), id 0MKwpI-1GJS0L0yvY-0004MU; Sat, 02 Sep 2006 11:41:33 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Sat, 02 Sep 2006 09:34:15 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1157189655.27.0.130858794089.issue15@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Provags-ID: kundenserver.de abuse@kundenserver.de login:518a04bce8f5fdb19ebc1cc661140948 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Ecrit] [issue15] Error Codes X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: LoST Issue Tracker List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes Tschofenig added the comment: A proposal for error codes can be found in Section 8 of the pre -01 version= :=20 http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/draft-ietf-ecrit-lost-0= 1=2Etxt ---------- nosy: +ecrit status: done-cbb -> chatting __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Sep 02 05:43:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJS2a-0003Qn-9A; Sat, 02 Sep 2006 05:43:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJS2Y-0003Qg-CZ for ecrit@ietf.org; Sat, 02 Sep 2006 05:43:50 -0400 Received: from moutng.kundenserver.de ([212.227.126.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJS2X-0001Qr-0j for ecrit@ietf.org; Sat, 02 Sep 2006 05:43:50 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1GJS2W1KSA-0003JT; Sat, 02 Sep 2006 11:43:48 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Sat, 02 Sep 2006 09:36:30 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1157189790.34.0.0938093025449.issue14@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Provags-ID: kundenserver.de abuse@kundenserver.de login:518a04bce8f5fdb19ebc1cc661140948 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Ecrit] [issue14] Transport Mechanism X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: LoST Issue Tracker List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes Tschofenig added the comment: A proposal for the LoST transport can be found in Section 9 of the pre -01=20 version:=20 http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/draft-ietf-ecrit-lost-0= 1=2Etxt Only Lost over HTTP/HTTPS is defined. Other transports can be added later (= into=20 separate documents, if there is a need).=20 As a consequence LoST is kept simple (from an implementation and specificat= ion=20 point of view). ---------- nosy: +ecrit status: chatting -> done-cbb __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Sep 02 05:55:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJSDx-0003Pk-C9; Sat, 02 Sep 2006 05:55:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJSDw-0003OQ-4I for ecrit@ietf.org; Sat, 02 Sep 2006 05:55:36 -0400 Received: from moutng.kundenserver.de ([212.227.126.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJSDs-0001zJ-Mf for ecrit@ietf.org; Sat, 02 Sep 2006 05:55:36 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1GJSDs1ItZ-0003KM; Sat, 02 Sep 2006 11:55:32 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Sat, 02 Sep 2006 09:48:14 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1157190494.29.0.304442927108.issue3@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Provags-ID: kundenserver.de abuse@kundenserver.de login:518a04bce8f5fdb19ebc1cc661140948 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Ecrit] [issue3] List all Services Functionality X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: LoST Issue Tracker List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes Tschofenig added the comment: The pre -01 version indicates that only immediate child elements are return= ed=20 in a listServices query. Furthermore, it indicates that location informatio= n=20 must be provided with the query. See=20 http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/draft-ietf-ecrit-lost-0= 1=2Etxt ---------- status: chatting -> done-cbb __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 04 10:04:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKF3K-0000fU-4H; Mon, 04 Sep 2006 10:03:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKF3J-0000fO-1p for ecrit@ietf.org; Mon, 04 Sep 2006 10:03:53 -0400 Received: from [86.59.12.252] (helo=sil1.mah.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKF3F-0007Jq-7W for ecrit@ietf.org; Mon, 04 Sep 2006 10:03:53 -0400 Received: from sip.mah.priv.at ([81.223.16.194] helo=[192.168.1.77]) by sil1.mah.priv.at with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1GKF36-0004Dm-1J; Mon, 04 Sep 2006 16:03:42 +0200 Message-ID: <44FC322F.6080805@mah.priv.at> Date: Mon, 04 Sep 2006 16:03:27 +0200 From: Michael Haberler User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "Rosen, Brian" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 81.223.16.194 X-SA-Exim-Mail-From: ml1234@mah.priv.at X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-26) on sil1.mah.priv.at X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.4 Subject: Re: [Ecrit] FW: LoST synchronous query and referals X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on sil1.mah.priv.at) X-Spam-Score: 0.5 (/) X-Scan-Signature: efc5d1db3729b4b7031f1bb5f5a30ae3 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: , Errors-To: ecrit-bounces@ietf.org Rosen, Brian schrieb: > Michael > > The question I'm asking is not how long an HTTP query takes. The > question I'm asking is how long a point-in-polygon operation takes. The > question I raised was for a geo query. > since you asked, I looked into that question. Here is what I found. I have a data collection of shapes for Austria which would map quite nicely on the to-be-expected shapes in an actual LoST Server ( Republic of Austria, counties, districts, communities, and because I had them at hand, calling areas. ). I'm interested how the point-in-polygon (actually shape-in-polygon in the general case) operation behaves. I only tested point-in-polygon. Object statistics - counts, areas, and number of points-in-polygon are in the Excel file (see link below). One would execute a geo LoST query in two steps: first, intersect the point (or in case of a cell, its bounding box) with the bounding boxes of the requested service areas. So this gives a set of candidate service areas. All candidate areas need to be tested for exact match if there is more than one BB match. so in postgresql/postgis, the query would be something like: select * from servicearea where (create location geometry here) AND (qualify service area type here) AND location.geometry && servicearea.geometry AND (1) within (location.geometry, servicearea.geometry); (2) The interesting operations are (1) - the bounding box intersection test and (2) the actual test for arbitrary shapes. The BB test would involve a spatial index and probably very fast (it is). The within-polygon test calls upon a function (in case of Postgis from the GEOS library), which would much slower. My questions were: - how many matching BB's might be expected on average (and maximum, while we are at it)? - what's the cost of the bounding box test? - what's the cost of the within() operator on the result set? Results are here: http://static.mah.priv.at/public/lost-perf.xls . Comment: To determine the average result set size of the BB test, I used a set of 114.000 points within Austria, and recorded for each structure the count of matching bounding boxes for that point. Depending on the shape, there's an average of 1.5 - 1.95 bounding box matches per point. So that means for any given point, one would have to run within(point, shape) less than two times on average. The maximum set size was 7 (the smaller the structure, the larger the average result size and also the maximum). - The BB test costs next to nothing - testing a point wether it lies in Austria's BB costs something like 5 mikrosecs. - the cost of the within() operator depends heavily on the number of points in the polygon. At 200 points, the test time is less than 20 microseconds. At 16.000 points, it can be on the order of 50 milliseconds. - the higher number of BB matches for smaller structures is more-than-overcompensated by the higher speed of the within() test due to less edge points per polygon. - for average service areas (like district or community) is always below 1msec total So I guess that backs up my statement, Brian - especially you folks with your many trivially-shaped counties and states in the US would be extra fast ;-) Note that I did not try any optimization on the data itself, or the system (os+dbms) and there would be several ways which could speed up operations significantly, if that is needed at all. One strategy could be to sub-divide a shape by inscribing fully contained rectangles, which would reduce most matches to an extremely fast spatial index search. The remaining polygon "snippets" would be of significantly reduced complexity and therefore fast as well. Another approach would be reduction of the complexity of the remaining shape tests. One would have to determine the needed accuracy, and could e.g use the Douglas-Peuker algorithm to reduce the number of points per polygon. Souch an optimzation would involve specifying an accuracy parameter (like +/- 5m) and one would have to "treat" all neighbouring polygons identically so as not to "lose coverage" at the boundaries. See for example http://foo.keybit.net/~simm/swfview.swf?units=dd&autocolor=1&alpha=50&map=maps/vectors/simp/all/simp.swf and http://postgis.refractions.net/pipermail/postgis-users/2003-February/002146.html . For civic addresses, all this can be pre-computed and e.g. updated on-demand with a trigger - civic would be index compares only. Vehicle was postgis 8.1, linux 2.6.17, dual xeon 2.4 ghz, 1 GB, scsi raid. -Michael ps: If you play with such queries and PostGIS - note that these queries originally suffered from the problem described in http://postgis.refractions.net/docs/ch05.html (small tables with large geometries) which cause the Postgresql query planner not to use an index even if present. This was fixed by introducing an explicit bbox geometry column and setting it to envelope(geometry). psps: this is not a scientific study, but back-of-the-envelope scribblings - in particular I hope I got the execution count figures right. > I do thing the "avalanche restart" problem should be addressed in > -phonebcp. I lost track of that, Jonathan was working on it. A very > quick Google query shows it's mentioned in -outbound and -overload, but > I don't see the randomization at the client end. > > Brian > > >> -----Original Message----- >> From: Michael Haberler [mailto:mah@inode.at] >> Sent: Friday, September 01, 2006 2:03 AM >> To: Rosen, Brian >> Cc: Henning Schulzrinne; Ecrit@Ietf.Org >> Subject: Re: [Ecrit] FW: LoST synchronous query and referals >> >> Rosen, Brian schrieb: >> >>> Do you really get a few millisecond response to a geo query with a >>> > full > >>> set of polygons? I thought it was a bit more (but not a whole lot >>> more). >>> >>> >> sub-5ms is doable with standard Apache / DBMS / PC platforms >> >> I wouldnt be concerned much about steady-state load but more the >> > convoy > >> effects after a major net outage, when many devices try to fetch >> concurrently >> >> analogy from my ISP past: an E3/T3 outage and re-sync on a fully >> > loaded > >> dialup server used to have spectacular effects on the Radius servers >> > (up > >> to 480 instantaneous session disconnects, and a clogged queue of >> > access > >> requests/session starts thereafter) >> >> this affects more the L7 location aquisition protocol than LoST, >> > though > >> -Michael >> >> >>> Brian >>> >>> >>> >>>> -----Original Message----- >>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>> Sent: Thursday, August 31, 2006 5:30 PM >>>> To: Rosen, Brian >>>> Cc: Ecrit@Ietf.Org >>>> Subject: Re: [Ecrit] FW: LoST synchronous query and referals >>>> >>>> The difference between the response time for a loaded (but not >>>> collapsing) and unloaded server is likely to be no more than 1:10, >>>> > at > >>>> most. This is based on some extrapolation from SIP server >>>> > measurements > >>>> we have done; in most systems, response time follows the classical >>>> hockey stick trajectory, with an extremely rapid rise to infinity >>>> > when > >>>> the load starts to exceed 80 or 90% of capacity. (The knee of the >>>> >>>> >>> curve >>> >>> >>>> and the slopes depend on the variability of the arrival and >>>> > service > >>>> process; details are in any book on queueing theory.) >>>> >>>> In other words, the chance that waiting a long time will help is >>>> >>>> >>> small. >>> >>> >>>> The server is either operating in the 80%-or-below load and you'll >>>> > get > >>>> an answer almost immediately or it is just as likely in the >>>> > collapsing > >>>> phase where any amount of waiting isn't going to help much. For >>>> > these > >>>> systems, it is much better to limit the queue size to a small >>>> > number > >>>> (say, 10), as that prevents congestion collapse. Increasing the >>>> > queue > >>>> size will not significantly improve the throughput. >>>> >>>> Example: For the classical M/M/1 system, a load of 0.9 produces a >>>> >>>> >>> queue >>> >>> >>>> length of 10, so making the queue larger will only yield, at most, >>>> > 10% > >>>> more throughput. 20 gives you 95%, 100 pushes it to 99% load, so >>>> > lots > >>> of >>> >>> >>>> waiting for minuscule performance gains. (A real system is likely >>>> > to > >>>> have smaller variability.) The TCP listen queue does this already; >>>> > I > >>>> think it's typically set to 5. >>>> >>>> Typical service times without load should be on the order of a few >>>> milliseconds if you want to support more than 100 request/seconds. >>>> >>>> >>> Thus, >>> >>> >>>> a queue of 10 might yield you a waiting time of maybe 50 ms. >>>> >>>> In other words, not a major issue if the system design is at all >>>> competent. >>>> >>>> Henning >>>> >>>> >>>> Rosen, Brian wrote: >>>> >>>> >>>>> And I made the same mistake twice before Andy corrected me. >>>>> >>>>> -----Original Message----- >>>>> From: Rosen, Brian >>>>> Sent: Thursday, August 31, 2006 2:13 PM >>>>> To: GEOPRIV >>>>> Subject: LoST synchronous query and referals >>>>> >>>>> I think we all imagine the LoST server to be a synchronous >>>>> query/response: from a single port open to the server, you send a >>>>> >>>>> >>> query >>> >>> >>>>> and wait for the response before sending another query. >>>>> >>>>> Give a little thought to system architecture, where we are >>>>> > expecting > >>> all >>> >>> >>>>> devices to query LoST periodically (with periodicity in perhaps >>>>> > tens > >>> of >>> >>> >>>>> hours to days), or when they move out of the region/boundary >>>>> >>>>> >>> supplied. >>> >>> >>>>> That makes the query load on the server fairly high, but not >>>>> > really > >>> too >>> >>> >>>>> bad. Certainly, a synchronous response is still appropriate, with >>>>> possibly the server permitting many simultaneous ports open. We >>>>> > do > >>>>> expect to see many non-authoritative copies of the authoritative >>>>> >>>>> >>> data to >>> >>> >>>>> spread load. >>>>> >>>>> Now, suppose there was a bulk querier. Could be a LIS >>>>> > periodically > >>>>> revalidating locations for example, but suppose it was the E-CSCF >>>>> > in > >>> a >>> >>> >>>>> 3GPP environment. I chose that because response time there >>>>> > matters, > >>> and >>> >>> >>>>> it may very well have more than one outstanding call at a time. >>>>> >>>>> Now, recall that there may be a referral mechanism: you ask a >>>>> >>>>> >>> question, >>> >>> >>>>> and the local server may not have the answer, but may refer to >>>>> >>>>> >>> another >>> >>> >>>>> server for resolution. We don't have details on that. >>>>> >>>>> If the query is actually forwarded by the original server, and the >>>>> response comes back through that server, then we do have a >>>>> > problem? > >>> A >>> >>> >>>>> query could take a long time to complete. Is that a problem worth >>>>> worrying about? How do we address it? I'm not asking for an >>>>> asynchronous query. I think that is the wrong direction. It may >>>>> > be > >>>>> that the referral is NOT a forward, but a redirect. That would >>>>> > make > >>> the >>> >>> >>>>> server not have to wait to respond. >>>>> >>>>> I think a high volume querier could have multiple persistent TCP >>>>> connections maintained (if the protocol is TCP based) and choose >>>>> > an > >>>>> available one as the way to handle the routine cases. If the >>>>> > server > >>>>> multithreads, that combination may even work for a long duration >>>>> >>>>> >>> query. >>> >>> >>>>> Brian >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>> >>>>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> >>> > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 04 14:03:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKImd-00071C-1d; Mon, 04 Sep 2006 14:02:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKImc-000717-3r for ecrit@ietf.org; Mon, 04 Sep 2006 14:02:54 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GKIma-0003OW-M6 for ecrit@ietf.org; Mon, 04 Sep 2006 14:02:54 -0400 Received: (qmail invoked by alias); 04 Sep 2006 18:02:51 -0000 Received: from p54987D94.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.125.148] by mail.gmx.net (mp045) with SMTP; 04 Sep 2006 20:02:51 +0200 X-Authenticated: #29516787 Message-ID: <44FC6A4B.4080604@gmx.net> Date: Mon, 04 Sep 2006 20:02:51 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [Ecrit] draft-ietf-ecrit-lost-01.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, we have just submitted a draft update. Please find it here: http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/draft-ietf-ecrit-lost-01.txt If you look at the diff between -00 and -01 then you will notice the following changes: * XML schema was replaced by a Relax NG schema. Section 13 contains the Relax NG schema in the compact form. Appendix A contains the RELAX NG schema in XML syntax. Schema elements itself got modified. This aspect resolved issue 13: http://www.tschofenig.priv.at:8080/lost/issue13 * Section 7 contains an update to the List Services Query/Response message. This aspect resolved issue 3: http://www.tschofenig.priv.at:8080/lost/issue3 * Section 8 contains status codes. This aspect resolved issue 15: http://www.tschofenig.priv.at:8080/lost/issue15 * Section 9 provides information about the transport using HTTP & HTTPS. This aspect resolved issue 14: http://www.tschofenig.priv.at:8080/lost/issue14 * Section 10 defines LoST URLs. This is a starting point for addressing issue 5 and 11. http://www.tschofenig.priv.at:8080/lost/issue5 http://www.tschofenig.priv.at:8080/lost/issue11 * Section 15 provides IANA considerations. * Other editorial fixes There are a few more open issues (as you can recognize at http://www.tschofenig.priv.at:8080/lost) but we would very much appreciate comments to get closer to an implementable specification. Ciao Hannes PS: Just before we submitted the draft we noticed that the acknowledgment section is still empty. We are going to fix this with the next draft update. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 05 10:33:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKbyz-0006AE-TW; Tue, 05 Sep 2006 10:32:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKbyy-00069J-6O for ecrit@ietf.org; Tue, 05 Sep 2006 10:32:56 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKbtM-0005xS-0A for ecrit@ietf.org; Tue, 05 Sep 2006 10:27:09 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GKbtF-0005rg-PQ; Tue, 05 Sep 2006 09:27:02 -0500 From: "Brian Rosen" To: "'Marc Linsner'" , "'Andrew Newton'" Subject: RE: [Ecrit] faux privacy concerns Date: Tue, 5 Sep 2006 10:27:03 -0400 Message-ID: <003601c6d0f7$5d46fa30$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <010701c6ce0f$384dc550$2a0d0d0a@amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbODg0GKz3Y+MpeSFuSa11QPb4pfgAAQZqgALnapLA= X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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: , Errors-To: ecrit-bounces@ietf.org There are many attacks that are going to work. Denial of service is one of them, and whether you use TLS or not. A downgrade attack will also work. I don't see that problem even within an order of magnitude of the problem of wholesale forgery of location. I really see forgery as an actual problem, affecting a lot of people, compared to a downgrade attack, affecting a specific person placing an emergency call. Think about what you need to organize forgery, and compare that with what you need to do a downgrade attack. The former is easy, the latter is quite hard, albeit possible. I DO think analyzing attacks that assume an attacker can listen to any packet and generate any packet is the correct way to look at the security of the system. If I could think of a practical way to prevent this kind of attack, I'd support it. I think the effort involved in trying TLS and falling back is small. I think the benefit is fairly large, but not overwhelming. I think the tradeoff favors doing it. Brian > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Friday, September 01, 2006 5:40 PM > To: 'Andrew Newton' > Cc: 'Ecrit@Ietf.Org' > Subject: RE: [Ecrit] faux privacy concerns > > > > On Sep 1, 2006, at 5:13 PM, Marc Linsner wrote: > > > Now you're listening, before you were messing with > > packets...different > > > paradigm, I think. Listening to TLS LoST query gains you > > nothing. > > > Not the > > > expert, but listening appears easier than messing with packets. > > > > Yes, but it doesn't take much more. After all, script > > kiddies have the tools at hand to synthesize packets. > > > > > Again, not the expert, but I heard the marketing. TLS LoST queries: > > > > > > 1) The querier knows if the data has been messed with. > > > 2) A chance that an after-the-fact audit will reveal whether the > > > responding LoST server is a real one. > > > > Actually, the querier probably just knows that TLS didn't > > work and that they dropped back. Unless they are doing > > active intrusion detection, they probably don't know somebody > > messed with their stuff. A scheme that is an order of > > magnitude more chatty and latent without useful security is > > likely to be of little comfort to those doing a postmortem > > (in some cases, literally). > > You certainly add a level of comfort to on-line banking applications! > > :^) > > -Marc- > > > > > > > True? > > > Does the benefit outweigh the effort? > > > > Absolutely not. > > > > -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 Sep 05 10:37:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKc3Y-0000JU-D9; Tue, 05 Sep 2006 10:37:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKc3W-0000J7-Rc for ecrit@ietf.org; Tue, 05 Sep 2006 10:37:38 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKc3V-0008Nl-LI for ecrit@ietf.org; Tue, 05 Sep 2006 10:37:38 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Tue, 05 Sep 2006 10:37:31 -0400 id 01588188.44FD8BAC.00002CF1 Message-ID: <44FD8BAC.1000506@hxr.us> Date: Tue, 05 Sep 2006 10:37:32 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] faux privacy concerns References: <003601c6d0f7$5d46fa30$640fa8c0@cis.neustar.com> In-Reply-To: <003601c6d0f7$5d46fa30$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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: , Errors-To: ecrit-bounces@ietf.org Brian Rosen wrote: > There are many attacks that are going to work. Denial of service is one of > them, and whether you use TLS or not. A downgrade attack will also work. > I don't see that problem even within an order of magnitude of the problem of > wholesale forgery of location. I really see forgery as an actual problem, > affecting a lot of people, compared to a downgrade attack, affecting a > specific person placing an emergency call. Think about what you need to > organize forgery, and compare that with what you need to do a downgrade > attack. The former is easy, the latter is quite hard, albeit possible. Forgery of what? > I think the effort involved in trying TLS and falling back is small. I > think the benefit is fairly large, but not overwhelming. I think the > tradeoff favors doing it. I completely disagree. You are hobbling the system with much more traffic than it needs to handle, for a security benefit that is easily thwarted and a privacy benefit that is of secondary need. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 05 10:57:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKcML-0000wj-91; Tue, 05 Sep 2006 10:57:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKcMK-0000we-Ov for ecrit@ietf.org; Tue, 05 Sep 2006 10:57:04 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKcLt-0003B8-3U for ecrit@ietf.org; Tue, 05 Sep 2006 10:57:04 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GKcLm-0000LQ-QV; Tue, 05 Sep 2006 09:56:31 -0500 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: [Ecrit] faux privacy concerns Date: Tue, 5 Sep 2006 10:56:32 -0400 Message-ID: <004b01c6d0fb$7be45c90$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <44FD8BAC.1000506@hxr.us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbQ+NPE1WBbnfKzSsqQR/tTZbazyQAAgXOQ X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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: , Errors-To: ecrit-bounces@ietf.org Forgery of location: a script kiddie creates a call with a totally forged identity and location. Responder resources are sent on a wild goose chase. The current 9-1-1 system does not allow this. Location cannot be forged. Neither can identity. There is no evidence that this will hobble the system. The traffic is such that reasonable servers can easily handle the expected load WITH TLS. The security benefit is not easily thwarted. That it cannot thwart other attacks (like downgrade attacks) does not diminish the fact that forgery is a real, likely-to-happen concern, and the other attacks, while definitely feasible, are much less likely to happen, and cause much less damage when they do. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Tuesday, September 05, 2006 10:38 AM > To: Brian Rosen > Cc: 'Marc Linsner'; 'Ecrit@Ietf.Org' > Subject: Re: [Ecrit] faux privacy concerns > > Brian Rosen wrote: > > There are many attacks that are going to work. Denial of service is one > of > > them, and whether you use TLS or not. A downgrade attack will also > work. > > I don't see that problem even within an order of magnitude of the > problem of > > wholesale forgery of location. I really see forgery as an actual > problem, > > affecting a lot of people, compared to a downgrade attack, affecting a > > specific person placing an emergency call. Think about what you need to > > organize forgery, and compare that with what you need to do a downgrade > > attack. The former is easy, the latter is quite hard, albeit possible. > > Forgery of what? > > > I think the effort involved in trying TLS and falling back is small. I > > think the benefit is fairly large, but not overwhelming. I think the > > tradeoff favors doing it. > > I completely disagree. You are hobbling the system with much more traffic > than it needs to handle, for a security benefit that is easily thwarted > and > a privacy benefit that is of secondary need. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 05 11:10:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKcYl-00071D-P2; Tue, 05 Sep 2006 11:09:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKcYk-00070J-I5 for ecrit@ietf.org; Tue, 05 Sep 2006 11:09:54 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKcYf-0006Bs-Bn for ecrit@ietf.org; Tue, 05 Sep 2006 11:09:54 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Tue, 05 Sep 2006 11:09:35 -0400 id 01588110.44FD932F.0000345D Message-ID: <44FD9330.1000201@hxr.us> Date: Tue, 05 Sep 2006 11:09:36 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] faux privacy concerns References: <004b01c6d0fb$7be45c90$640fa8c0@cis.neustar.com> In-Reply-To: <004b01c6d0fb$7be45c90$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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: , Errors-To: ecrit-bounces@ietf.org Brian Rosen wrote: > Forgery of location: a script kiddie creates a call with a totally forged > identity and location. Responder resources are sent on a wild goose chase. > > The current 9-1-1 system does not allow this. Location cannot be forged. > Neither can identity. > > There is no evidence that this will hobble the system. The traffic is such > that reasonable servers can easily handle the expected load WITH TLS. The > security benefit is not easily thwarted. That it cannot thwart other > attacks (like downgrade attacks) does not diminish the fact that forgery is > a real, likely-to-happen concern, and the other attacks, while definitely > feasible, are much less likely to happen, and cause much less damage when > they do. You are right that forgery is not easily thwarted by server side certs and TLS, because that scheme never protected against forgery in the first place. I'd also like to point out that even if you do institute some sort of forgery protection against a LoST server, you still haven't solved the problem. Forgery of location information against a PSAP is a conveyance issue. An attacker can be honest with a LoST server all day long and still lie to a PSAP. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 05 11:14:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKccw-0008AZ-3y; Tue, 05 Sep 2006 11:14:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKccu-00089p-0q for ecrit@ietf.org; Tue, 05 Sep 2006 11:14:12 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKccr-0007Df-Oz for ecrit@ietf.org; Tue, 05 Sep 2006 11:14:11 -0400 Received: from lion.cs.columbia.edu (IDENT:2rwZOtsEqjSrIVYzERZ0ph/H4E7G6IFT@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k85FE6Gb026881 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 5 Sep 2006 11:14:06 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k85FE3g7007265 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 5 Sep 2006 11:14:06 -0400 Message-ID: <44FD9436.2010705@cs.columbia.edu> Date: Tue, 05 Sep 2006 11:13:58 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] faux privacy concerns References: <004b01c6d0fb$7be45c90$640fa8c0@cis.neustar.com> In-Reply-To: <004b01c6d0fb$7be45c90$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter1.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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: , Errors-To: ecrit-bounces@ietf.org Brian Rosen wrote: > Forgery of location: a script kiddie creates a call with a totally forged > identity and location. Responder resources are sent on a wild goose chase. > > The current 9-1-1 system does not allow this. Location cannot be forged. > Neither can identity. This isn't really true. While it is not possible for somebody in Nigeria to pretend to be in Toledo, most cellular callers in rural areas can pretend to be in areas spanning dozens of square miles of territory, which yields just about the same wild goose chase. With no-SIM phones or stolen phones, the calls are also anonymous. I'm not arguing that this is desirable, just that we shouldn't pretend that this is a new threat. > > There is no evidence that this will hobble the system. The traffic is such > that reasonable servers can easily handle the expected load WITH TLS. The > security benefit is not easily thwarted. That it cannot thwart other > attacks (like downgrade attacks) does not diminish the fact that forgery is > a real, likely-to-happen concern, and the other attacks, while definitely > feasible, are much less likely to happen, and cause much less damage when > they do. > As discussed before, I believe that identity assertion is a much more practical and likely-to-be-successful approach to severely curtailing malicious or prank calls, together with some standard network-level sanity checks that tags calls from Outer Mongolia. Unlike in the cellular world, where a monthly subscription fee makes it necessary to allow for no-SIM calls, the need is far less in VoIP. I can have a fallback emergency "carrier" with authentication and authorization that requires no subscription fees. Thus, maybe we should start with defining requirements, not assuming solutions. There may well be other solutions that are more readily deployable and avoid the issues being discussed here. For example, it may be sufficient to have an "access provider cert" that simply attests that I'm currently using a particular ISP or maybe a particular POP or DSLAM. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 05 11:22:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKclL-0005MR-2Z; Tue, 05 Sep 2006 11:22:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKclJ-0005ME-QI for ecrit@ietf.org; Tue, 05 Sep 2006 11:22:53 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKclH-0000GE-IO for ecrit@ietf.org; Tue, 05 Sep 2006 11:22:53 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GKcl5-0002nE-Sl; Tue, 05 Sep 2006 10:22:40 -0500 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: [Ecrit] faux privacy concerns Date: Tue, 5 Sep 2006 11:22:42 -0400 Message-ID: <00c201c6d0ff$23301770$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <44FD9330.1000201@hxr.us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbQ/U/Bsh5t55XXSreAlwLTUAyvewAAJ5rw X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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: , Errors-To: ecrit-bounces@ietf.org > I'd also like to point out that even if you do institute some sort of > forgery protection against a LoST server, you still haven't solved the > problem. Forgery of location information against a PSAP is a conveyance > issue. An attacker can be honest with a LoST server all day long and > still > lie to a PSAP. Absolutely. I'm trying to get everything to work the same way, for the same benefit. I am guilty of mixing parts here, forgery is MORE of a concern with conveyance. The biggest benefit to TLS in LoST is privacy. If the endpoint sends its location, you know it belongs to the endpoint. There is a smaller concern about integrity protection. You don't have a client authorization problem on the general query, but you do have a server side issue: the client would like to know that it is talking to the entity it thinks it is. I'd like to do better than that (have a real CA for the LoST servers), but that is probably not realistic most places. In LoST, I think we can leave it up to the client. The server MUST support TLS. The client can choose to use it or not. Wording around that would be in -phonebcp. Would you not agree that MUST IMPLEMENT TLS is a reasonable requirement? Would you not agree that even with server certs, you do get privacy, albeit downgrade attacks are possible? Is that not still a fairly significant gain? From the client point of view, wouldn't it seem like trying TLS to get the privacy is a worthy use of the cycles? Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 05 11:29:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKcrG-0003G0-4p; Tue, 05 Sep 2006 11:29:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKcrF-0003EV-9c for ecrit@ietf.org; Tue, 05 Sep 2006 11:29:01 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKcr0-0001nr-It for ecrit@ietf.org; Tue, 05 Sep 2006 11:29:01 -0400 Received: from lion.cs.columbia.edu (IDENT:aaWA8VRt9ed/KzQ9GAzOwZqFNYm5ZR78@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k85FSjGb001275 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 5 Sep 2006 11:28:45 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k85FSjg7008226 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 5 Sep 2006 11:28:45 -0400 Message-ID: <44FD97A7.6020008@cs.columbia.edu> Date: Tue, 05 Sep 2006 11:28:39 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "ECRIT WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter2.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Ecrit] LoST open issue: Do we need a URL? 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: , Errors-To: ecrit-bounces@ietf.org It is not clear that LoST really needs its own URL scheme, since it is unlikely to appear on web pages or other places that would necessitate such a mechanism. Currently, the definition is extremely trivial and seems to impose no significant complexity, so I'm tempted to simply retain it under the "does no harm" category, but if somebody would like to speak to this point, please do so soon. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 05 11:32:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKcuL-00049G-NB; Tue, 05 Sep 2006 11:32:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKcuK-000499-0F for ecrit@ietf.org; Tue, 05 Sep 2006 11:32:12 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKcuI-0002gh-N6 for ecrit@ietf.org; Tue, 05 Sep 2006 11:32:11 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GKcuB-0003bz-IU; Tue, 05 Sep 2006 10:32:04 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Ecrit] faux privacy concerns Date: Tue, 5 Sep 2006 11:32:05 -0400 Message-ID: <00c901c6d100$7350d400$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <44FD9436.2010705@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbQ/eyDVxF8dLv2QYGxR050OaawRQAAUMew X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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: , Errors-To: ecrit-bounces@ietf.org > This isn't really true. While it is not possible for somebody in Nigeria > to pretend to be in Toledo, most cellular callers in rural areas can > pretend to be in areas spanning dozens of square miles of territory, > which yields just about the same wild goose chase. With no-SIM phones or > stolen phones, the calls are also anonymous. > > I'm not arguing that this is desirable, just that we shouldn't pretend > that this is a new threat. No, actually, a Phase II carrier network has a 50 meter accuracy everywhere, and it's not forgeable. The silliness that an uninitialized mobile can't deliver location is true, but should never have been allowed. It's a big hole. ...snip... > > As discussed before, I believe that identity assertion is a much more > practical and likely-to-be-successful approach to severely curtailing > malicious or prank calls, together with some standard network-level > sanity checks that tags calls from Outer Mongolia. Well, identity does help, no question about it. Is it sufficient? I don't think so, primarily because I think we have to assume no carrier is possible. If there is no carrier, identity assertion becomes problematic. If we outlaw Marc's home proxy delivering calls to the PSAP, then we might be able to state that identity is sufficient. Hmmm, maybe not, because Sierra Leone VoIP Service Pty could make an assertion, but who would trust it? Also note, of course, that identity helps you after the fact. Possibly the identity has more to do with the access network? > > Unlike in the cellular world, where a monthly subscription fee makes it > necessary to allow for no-SIM calls, the need is far less in VoIP. I can > have a fallback emergency "carrier" with authentication and > authorization that requires no subscription fees. Sure, although I doubt this will happen. For what it's worth, the lack of identity and location is sufficient to cause the 9-1-1 guys to actually want to outlaw the whole thing. They'd probably rather it worked well, but would prefer not work at all to work poorly. No one believes that the regulation to require it of mobile carriers will be changed however. > > Thus, maybe we should start with defining requirements, not assuming > solutions. There may well be other solutions that are more readily > deployable and avoid the issues being discussed here. For example, it > may be sufficient to have an "access provider cert" that simply attests > that I'm currently using a particular ISP or maybe a particular POP or > DSLAM. Yeah, maybe. Need a system level discussion though, I think, not just LoST centric. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 05 11:43:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKd4o-0007Jt-Kv; Tue, 05 Sep 2006 11:43:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKd4n-0007Iz-83 for ecrit@ietf.org; Tue, 05 Sep 2006 11:43:01 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKd4m-0003wX-21 for ecrit@ietf.org; Tue, 05 Sep 2006 11:43:01 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Tue, 05 Sep 2006 11:42:54 -0400 id 0158817B.44FD9AFE.00005F4B Message-ID: <44FD9AFE.2000502@hxr.us> Date: Tue, 05 Sep 2006 11:42:54 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] faux privacy concerns References: <00c201c6d0ff$23301770$640fa8c0@cis.neustar.com> In-Reply-To: <00c201c6d0ff$23301770$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: , Errors-To: ecrit-bounces@ietf.org Brian Rosen wrote: > Would you not agree that MUST IMPLEMENT TLS is a reasonable requirement? That is a very reasonable requirement. > Would you not agree that even with server certs, you do get privacy, albeit > downgrade attacks are possible? You get privacy from somebody casually sniffing traffic. Anybody who wants it will get it. > Is that not still a fairly significant > gain? From the client point of view, wouldn't it seem like trying TLS to > get the privacy is a worthy use of the cycles? I guess it would be fairly harsh of me to judge somebody for placing far more emphasis on their location privacy than having their house fire extinguished. I'm just silly that way. So if somebody wants to configure their phone that way, we should let them. However, that is a far cry from suggesting that everybody SHOULD do it. And from a network point of view, it does have implications. In simple terms, it means the network will be overloaded that much faster. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 05 11:46:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKd85-0000VI-An; Tue, 05 Sep 2006 11:46:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKd84-0000VD-EP for ecrit@ietf.org; Tue, 05 Sep 2006 11:46:24 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKd82-0004kb-8Q for ecrit@ietf.org; Tue, 05 Sep 2006 11:46:24 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Tue, 05 Sep 2006 11:46:16 -0400 id 0158817B.44FD9BC8.00005FD8 Message-ID: <44FD9BC9.1000808@hxr.us> Date: Tue, 05 Sep 2006 11:46:17 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] LoST open issue: Do we need a URL? References: <44FD97A7.6020008@cs.columbia.edu> In-Reply-To: <44FD97A7.6020008@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ECRIT WG 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: , Errors-To: ecrit-bounces@ietf.org Henning Schulzrinne wrote: > > Currently, the definition is extremely trivial and seems to impose no > significant complexity, so I'm tempted to simply retain it under the > "does no harm" category, but if somebody would like to speak to this > point, please do so soon. My preference is to exclude it at the moment. There is harm in defining one now that might be incompatible with a future need requiring a beefier scheme. But other than that, yes it is harmless. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 05 11:48:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKd9l-0001Ib-NE; Tue, 05 Sep 2006 11:48:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKd9k-0001IQ-EO for ecrit@ietf.org; Tue, 05 Sep 2006 11:48:08 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKd9i-00050e-WD for ecrit@ietf.org; Tue, 05 Sep 2006 11:48:08 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GKd9c-00051r-EL; Tue, 05 Sep 2006 10:48:00 -0500 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: [Ecrit] faux privacy concerns Date: Tue, 5 Sep 2006 11:48:02 -0400 Message-ID: <00f101c6d102$ad9cc4f0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <44FD9AFE.2000502@hxr.us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbRAfYPf+X5Rl3GTwK5CCmpybXHNgAAEnDg X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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: , Errors-To: ecrit-bounces@ietf.org Okay, so maybe we've converged everywhere except what it says in -phonebcp about client behavior. I'll leave that until another day. For now, we know what the LoST document should say about it, if everyone else agrees: TLS is MUST Implement Server certs are required Would you accept: client certs are optional? Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Tuesday, September 05, 2006 11:43 AM > To: Brian Rosen > Cc: 'Ecrit@Ietf.Org' > Subject: Re: [Ecrit] faux privacy concerns > > Brian Rosen wrote: > > Would you not agree that MUST IMPLEMENT TLS is a reasonable requirement? > > That is a very reasonable requirement. > > > Would you not agree that even with server certs, you do get privacy, > albeit > > downgrade attacks are possible? > > You get privacy from somebody casually sniffing traffic. Anybody who > wants > it will get it. > > > Is that not still a fairly significant > > gain? From the client point of view, wouldn't it seem like trying TLS > to > > get the privacy is a worthy use of the cycles? > > I guess it would be fairly harsh of me to judge somebody for placing far > more emphasis on their location privacy than having their house fire > extinguished. I'm just silly that way. So if somebody wants to configure > their phone that way, we should let them. > > However, that is a far cry from suggesting that everybody SHOULD do it. > > And from a network point of view, it does have implications. In simple > terms, it means the network will be overloaded that much faster. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 05 11:54:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdG9-0003eg-K8; Tue, 05 Sep 2006 11:54:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdG7-0003dX-W6 for ecrit@ietf.org; Tue, 05 Sep 2006 11:54:43 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKdG6-0005rR-QJ for ecrit@ietf.org; Tue, 05 Sep 2006 11:54:43 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Tue, 05 Sep 2006 11:54:37 -0400 id 01588188.44FD9DBD.0000612E Message-ID: <44FD9DBD.1020801@hxr.us> Date: Tue, 05 Sep 2006 11:54:37 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] faux privacy concerns References: <00f101c6d102$ad9cc4f0$640fa8c0@cis.neustar.com> In-Reply-To: <00f101c6d102$ad9cc4f0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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: , Errors-To: ecrit-bounces@ietf.org Brian Rosen wrote: > TLS is MUST Implement Agreed. > Server certs are required I disagree. If a LoST administrator doesn't want to do it, then forcing it upon them is only gonna get an unpredictable result. Additionally, client implementers should be told that they need to be intimately aware of how their TLS work in case they do not recognize the server cert: in other words, they need to be very sure that their TLS library allows them to ignore unknown certs and continue the TLS conversation. Otherwise, they should simply not use it. > Would you accept: client certs are optional? Agreed with the similar warning as above, except geared toward server implementers. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 05 12:02:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdNs-0008OD-J5; Tue, 05 Sep 2006 12:02:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdNq-0008Ms-Ov for ecrit@ietf.org; Tue, 05 Sep 2006 12:02:42 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKdNo-0006g4-UQ for ecrit@ietf.org; Tue, 05 Sep 2006 12:02:42 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GKdNi-0006W5-AI; Tue, 05 Sep 2006 11:02:34 -0500 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: [Ecrit] faux privacy concerns Date: Tue, 5 Sep 2006 12:02:36 -0400 Message-ID: <00f201c6d104$b68c9a20$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <44FD9DBD.1020801@hxr.us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbRA5h7jsCJmiWoT1W58MIyIVFojQAAL1ug X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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: , Errors-To: ecrit-bounces@ietf.org > > Server certs are required > > I disagree. If a LoST administrator doesn't want to do it, then forcing > it > upon them is only gonna get an unpredictable result. Additionally, > client > implementers should be told that they need to be intimately aware of how > their TLS work in case they do not recognize the server cert: in other > words, they need to be very sure that their TLS library allows them to > ignore unknown certs and continue the TLS conversation. Otherwise, they > should simply not use it. > I'm sorry, I don't understand. Are you actually saying that TLS-with-server-certs should not be mandated, or are you saying that there needs to be text around a mandate that explains the issues? If TLS is MUST IMPLEMENT, then what else, besides server certs, is an acceptable MUST IMPLEMENT ciphersuite? I presume we otherwise would be saying RSA-1024, SHA-1/2, AES. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 05 12:03:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdOQ-000093-SH; Tue, 05 Sep 2006 12:03:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdOP-00006q-5C for ecrit@ietf.org; Tue, 05 Sep 2006 12:03:17 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKdON-0006jI-Ua for ecrit@ietf.org; Tue, 05 Sep 2006 12:03:17 -0400 Received: from lion.cs.columbia.edu (IDENT:p3Vj3/kptZcNk5SJzy1uuzjzKzdaW+D/@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k85G39Gb010730 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 5 Sep 2006 12:03:09 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k85G39g7010381 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 5 Sep 2006 12:03:09 -0400 Message-ID: <44FD9FB7.8040709@cs.columbia.edu> Date: Tue, 05 Sep 2006 12:03:03 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] faux privacy concerns References: <00c201c6d0ff$23301770$640fa8c0@cis.neustar.com> <44FD9AFE.2000502@hxr.us> In-Reply-To: <44FD9AFE.2000502@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter2.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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: , Errors-To: ecrit-bounces@ietf.org > I guess it would be fairly harsh of me to judge somebody for placing far > more emphasis on their location privacy than having their house fire > extinguished. I'm just silly that way. So if somebody wants to > configure their phone that way, we should let them. I think we need to be a bit more careful in this discussion in terms of timing. I'm hoping that in almost all cases, there will be no LoST query at the time of the call, since that query had already been done hours or days before, when the mobile moved into a new coverage area. Thus, a reasonable algorithm might be: (1) use TLS (server cert only) for LoST iff not in an emergency; if that fails for some reason, alert user and system operator (VSP); the bcp should suggest appropriate ways to determine ways to alert the operator (2) use plain-text LoST if the query is made at the time of the emergency call, given the trade-offs involved This approach also greatly reduces the impact of large-scale emergencies on the LoST infrastructure. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 05 12:10:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdVY-0003a8-M0; Tue, 05 Sep 2006 12:10:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdVV-0003Zu-Ml for ecrit@ietf.org; Tue, 05 Sep 2006 12:10:38 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKdVU-0007yt-FA for ecrit@ietf.org; Tue, 05 Sep 2006 12:10:37 -0400 Received: from lion.cs.columbia.edu (IDENT:dL/2F5HorVqm/o1CzunyPBoS9W1bhmWy@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k85GAWGb012658 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 5 Sep 2006 12:10:32 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k85GAVg7011035 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 5 Sep 2006 12:10:32 -0400 Message-ID: <44FDA172.3010800@cs.columbia.edu> Date: Tue, 05 Sep 2006 12:10:26 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] faux privacy concerns References: <00c901c6d100$7350d400$640fa8c0@cis.neustar.com> In-Reply-To: <00c901c6d100$7350d400$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter2.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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: , Errors-To: ecrit-bounces@ietf.org > No, actually, a Phase II carrier network has a 50 meter accuracy everywhere, > and it's not forgeable. Right. And the deployment of Phase II is universal :-) > be able to state that identity is sufficient. Hmmm, maybe not, because > Sierra Leone VoIP Service Pty could make an assertion, but who would trust > it? Also note, of course, that identity helps you after the fact. Possibly > the identity has more to do with the access network? We went through this already; with location or identity, you'll have the problem of entities making assertions that you haven't met before, be that Sierra Leone VoIP Service Pty or Brooklyn Bakery and Undertaker, LLC, for either location or identity. > Sure, although I doubt this will happen. For what it's worth, the lack of > identity and location is sufficient to cause the 9-1-1 guys to actually want > to outlaw the whole thing. They'd probably rather it worked well, but would > prefer not work at all to work poorly. No one believes that the regulation > to require it of mobile carriers will be changed however. I believe it when I see - it won't be a pretty sight after the AARP lobbyist has had it with the NENA lobbyist :-) > >> Thus, maybe we should start with defining requirements, not assuming >> solutions. There may well be other solutions that are more readily >> deployable and avoid the issues being discussed here. For example, it >> may be sufficient to have an "access provider cert" that simply attests >> that I'm currently using a particular ISP or maybe a particular POP or >> DSLAM. > Yeah, maybe. Need a system level discussion though, I think, not just LoST > centric. Location assertion has nothing to do with LoST and seems completely useless for LoST. > > Brian > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 05 12:10:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdVa-0003aS-U8; Tue, 05 Sep 2006 12:10:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdVZ-0003aJ-5X for ecrit@ietf.org; Tue, 05 Sep 2006 12:10:41 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKdVX-0007z3-OW for ecrit@ietf.org; Tue, 05 Sep 2006 12:10:41 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GKdVP-0007FW-GO; Tue, 05 Sep 2006 11:10:31 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Andrew Newton'" Subject: RE: [Ecrit] faux privacy concerns Date: Tue, 5 Sep 2006 12:10:34 -0400 Message-ID: <00f501c6d105$d306aeb0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <44FD9FB7.8040709@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbRBMffYrfyQfOUT8+J61J0ioPIOAAAE0bQ X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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: , Errors-To: ecrit-bounces@ietf.org Henning If this infrastructure was not needed in disaster situations, then I would agree with you. My problem is that experience suggests that everything you think will work in a disaster often doesn't, and stuff you weren't so sure about often does. I don't want an assumption made that the mapping you got yesterday is still valid. If it's all you got, and you can't get more, by all means use it, but TRY to get current data. That would mean rerunning the query at the time of a call. If there was a way to reliably signal a disaster, so we only did that when disaster struck, great, but that ain't gonna happen. To me, that means try with TLS and fall back, on every call. I think the timeouts on the try should be very short; if you get the TLS response real fast, use it, otherwise retry without it. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, September 05, 2006 12:03 PM > To: Andrew Newton > Cc: Brian Rosen; 'Ecrit@Ietf.Org' > Subject: Re: [Ecrit] faux privacy concerns > > > I guess it would be fairly harsh of me to judge somebody for placing far > > more emphasis on their location privacy than having their house fire > > extinguished. I'm just silly that way. So if somebody wants to > > configure their phone that way, we should let them. > > I think we need to be a bit more careful in this discussion in terms of > timing. I'm hoping that in almost all cases, there will be no LoST query > at the time of the call, since that query had already been done hours or > days before, when the mobile moved into a new coverage area. > > Thus, a reasonable algorithm might be: > > (1) use TLS (server cert only) for LoST iff not in an emergency; if that > fails for some reason, alert user and system operator (VSP); the bcp > should suggest appropriate ways to determine ways to alert the operator > > (2) use plain-text LoST if the query is made at the time of the > emergency call, given the trade-offs involved > > This approach also greatly reduces the impact of large-scale emergencies > on the LoST infrastructure. > > Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 05 12:14:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdZc-0004WO-0d; Tue, 05 Sep 2006 12:14:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdZa-0004Vb-S4 for ecrit@ietf.org; Tue, 05 Sep 2006 12:14:50 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKdZY-0008M2-DO for ecrit@ietf.org; Tue, 05 Sep 2006 12:14:50 -0400 Received: from lion.cs.columbia.edu (IDENT:+UtMfMT+ZdJGoq6MlL+YyeIIVF+t0aiH@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k85GEgGb013962 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 5 Sep 2006 12:14:42 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k85GEfg7011236 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 5 Sep 2006 12:14:42 -0400 Message-ID: <44FDA26C.4080602@cs.columbia.edu> Date: Tue, 05 Sep 2006 12:14:36 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] faux privacy concerns References: <00f501c6d105$d306aeb0$640fa8c0@cis.neustar.com> In-Reply-To: <00f501c6d105$d306aeb0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter2.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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: , Errors-To: ecrit-bounces@ietf.org We just have to disagree on this point. I believe LoST is the completely wrong system level to do short-time scale changes to PSAPs. This has nothing to do with TLS. We have many more suitable ways to do redirection that are actually designed for this purpose. Brian Rosen wrote: > Henning > > If this infrastructure was not needed in disaster situations, then I would > agree with you. > > My problem is that experience suggests that everything you think will work > in a disaster often doesn't, and stuff you weren't so sure about often does. > > I don't want an assumption made that the mapping you got yesterday is still > valid. If it's all you got, and you can't get more, by all means use it, > but TRY to get current data. > > That would mean rerunning the query at the time of a call. > > If there was a way to reliably signal a disaster, so we only did that when > disaster struck, great, but that ain't gonna happen. To me, that means try > with TLS and fall back, on every call. > > I think the timeouts on the try should be very short; if you get the TLS > response real fast, use it, otherwise retry without it. > > Brian > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 05 12:30:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdoi-00024v-I5; Tue, 05 Sep 2006 12:30:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdog-00023s-Sv for ecrit@ietf.org; Tue, 05 Sep 2006 12:30:26 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKdof-000253-IY for ecrit@ietf.org; Tue, 05 Sep 2006 12:30:26 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GKdoY-0000dG-3I; Tue, 05 Sep 2006 11:30:19 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Ecrit] faux privacy concerns Date: Tue, 5 Sep 2006 12:30:21 -0400 Message-ID: <010001c6d108$96612410$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <44FDA26C.4080602@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbRBmTulvAwczFCSyKotxn4Oukx5AAAMHIw X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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: , Errors-To: ecrit-bounces@ietf.org We may indeed have to disagree, but let me try one more time. The assumption you are making when you assert that there are more suitable ways to do redirection is that all of the calls originally intended for one destination (could be a PSAP) should go somewhere else; the redirection is always at the right hand side of the URL. That may not be the case, and you may not be able to make that work. I think we need the ability to actually change the routing (think changing the polygon that defines the area that gets a particular route if it was all map based). I'm not thinking this is done on a routine basis; we do that will TTLs and DNS. I'm thinking when the world falls apart, flexibility is the key to survival. I'll admit that for every scenario I can come up with, there is a better way to accomplish the task IF YOU THINK ABOUT IT BEFOREHAND. The problem is that we know we don't do a good job at predicting scenarios. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, September 05, 2006 12:15 PM > To: Brian Rosen > Cc: 'Andrew Newton'; 'Ecrit@Ietf.Org' > Subject: Re: [Ecrit] faux privacy concerns > > We just have to disagree on this point. I believe LoST is the completely > wrong system level to do short-time scale changes to PSAPs. This has > nothing to do with TLS. We have many more suitable ways to do > redirection that are actually designed for this purpose. > > Brian Rosen wrote: > > Henning > > > > If this infrastructure was not needed in disaster situations, then I > would > > agree with you. > > > > My problem is that experience suggests that everything you think will > work > > in a disaster often doesn't, and stuff you weren't so sure about often > does. > > > > I don't want an assumption made that the mapping you got yesterday is > still > > valid. If it's all you got, and you can't get more, by all means use > it, > > but TRY to get current data. > > > > That would mean rerunning the query at the time of a call. > > > > If there was a way to reliably signal a disaster, so we only did that > when > > disaster struck, great, but that ain't gonna happen. To me, that means > try > > with TLS and fall back, on every call. > > > > I think the timeouts on the try should be very short; if you get the TLS > > response real fast, use it, otherwise retry without it. > > > > Brian > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 05 12:30:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdpA-0002K9-Rv; Tue, 05 Sep 2006 12:30:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdpA-0002K3-4x for ecrit@ietf.org; Tue, 05 Sep 2006 12:30:56 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKdp4-00029Y-Vg for ecrit@ietf.org; Tue, 05 Sep 2006 12:30:56 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Tue, 05 Sep 2006 12:30:36 -0400 id 01588188.44FDA62D.00006A88 Message-ID: <44FDA62D.5080807@hxr.us> Date: Tue, 05 Sep 2006 12:30:37 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] faux privacy concerns References: <00c201c6d0ff$23301770$640fa8c0@cis.neustar.com> <44FD9AFE.2000502@hxr.us> <44FD9FB7.8040709@cs.columbia.edu> In-Reply-To: <44FD9FB7.8040709@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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: , Errors-To: ecrit-bounces@ietf.org Henning Schulzrinne wrote: > Thus, a reasonable algorithm might be: > > (1) use TLS (server cert only) for LoST iff not in an emergency; if that > fails for some reason, alert user and system operator (VSP); the bcp > should suggest appropriate ways to determine ways to alert the operator > > (2) use plain-text LoST if the query is made at the time of the > emergency call, given the trade-offs involved This is very reasonable, and sounds good to me. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 05 12:33:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdrn-0003ya-Oi; Tue, 05 Sep 2006 12:33:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdrl-0003yU-S4 for ecrit@ietf.org; Tue, 05 Sep 2006 12:33:37 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKdrk-0002SJ-Mv for ecrit@ietf.org; Tue, 05 Sep 2006 12:33:37 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Tue, 05 Sep 2006 12:33:30 -0400 id 01588188.44FDA6DB.00006ABB Message-ID: <44FDA6DB.4040801@hxr.us> Date: Tue, 05 Sep 2006 12:33:31 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] faux privacy concerns References: <00f501c6d105$d306aeb0$640fa8c0@cis.neustar.com> <44FDA26C.4080602@cs.columbia.edu> In-Reply-To: <44FDA26C.4080602@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed 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: , Errors-To: ecrit-bounces@ietf.org Henning Schulzrinne wrote: > We just have to disagree on this point. I agree. :) -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 05 13:01:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKeIb-0005UY-Nw; Tue, 05 Sep 2006 13:01:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKeIa-0005UP-Iw for ecrit@ietf.org; Tue, 05 Sep 2006 13:01:20 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKeIZ-00061x-AA for ecrit@ietf.org; Tue, 05 Sep 2006 13:01:20 -0400 Received: from lion.cs.columbia.edu (IDENT:5E3uM1WVCIrT4BipCMDowGK3hOk6T94j@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k85H1BGb025272 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 5 Sep 2006 13:01:11 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k85H1Ag7014204 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 5 Sep 2006 13:01:11 -0400 Message-ID: <44FDAD51.4070309@cs.columbia.edu> Date: Tue, 05 Sep 2006 13:01:05 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] faux privacy concerns References: <010001c6d108$96612410$640fa8c0@cis.neustar.com> In-Reply-To: <010001c6d108$96612410$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter2.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: "'Ecrit@Ietf.Org'" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The problem is that such solutions come with significant costs. In particular, they make any kind of local resolver caching fail - and since nobody knows ahead of time when the feature might be used, it becomes unusable to begin with. At the very least, I would like to make this "feature" (I'm sorry, I see this as a mis-feature) be made optional, so that an operator of a particular region can decide that the significant cost and operational implications are not worth the price. Brian Rosen wrote: > We may indeed have to disagree, but let me try one more time. > > The assumption you are making when you assert that there are more suitable > ways to do redirection is that all of the calls originally intended for one > destination (could be a PSAP) should go somewhere else; the redirection is > always at the right hand side of the URL. > > That may not be the case, and you may not be able to make that work. I > think we need the ability to actually change the routing (think changing the > polygon that defines the area that gets a particular route if it was all map > based). > > I'm not thinking this is done on a routine basis; we do that will TTLs and > DNS. I'm thinking when the world falls apart, flexibility is the key to > survival. > > I'll admit that for every scenario I can come up with, there is a better way > to accomplish the task IF YOU THINK ABOUT IT BEFOREHAND. The problem is > that we know we don't do a good job at predicting scenarios. > > Brian > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 05 13:08:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKePc-0000E1-7U; Tue, 05 Sep 2006 13:08:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKePb-0000Du-5q for ecrit@ietf.org; Tue, 05 Sep 2006 13:08:35 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKePZ-0006uk-SQ for ecrit@ietf.org; Tue, 05 Sep 2006 13:08:35 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k85H8HIG031980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 5 Sep 2006 10:08:18 -0700 Received: from [10.0.1.2] (vpn-10-50-0-166.qualcomm.com [10.50.0.166]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k85H8FME005704; Tue, 5 Sep 2006 10:08:17 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <44FD97A7.6020008@cs.columbia.edu> References: <44FD97A7.6020008@cs.columbia.edu> Date: Tue, 5 Sep 2006 10:08:14 -0700 To: Henning Schulzrinne , "ECRIT WG" From: Ted Hardie Subject: Re: [Ecrit] LoST open issue: Do we need a URL? Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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: , Errors-To: ecrit-bounces@ietf.org At 11:28 AM -0400 9/5/06, Henning Schulzrinne wrote: >It is not clear that LoST really needs its own URL scheme, since it is unlikely to appear on web pages or other places that would necessitate such a mechanism. > >Currently, the definition is extremely trivial and seems to impose no significant complexity, so I'm tempted to simply retain it under the "does no harm" category, but if somebody would like to speak to this point, please do so soon. If there is no URI scheme referrals are more difficult. I think it is worth doing for that reason alone. I also believe that the semantic difference between an http URI and a lost URI (where error codes are returned, to give the trivial example) is sufficient to warrant a URI scheme. Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 05 13:13:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKeUQ-0001oJ-Pa; Tue, 05 Sep 2006 13:13:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKeUP-0001oC-TK for ecrit@ietf.org; Tue, 05 Sep 2006 13:13:33 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKeUN-0007rY-2b for ecrit@ietf.org; Tue, 05 Sep 2006 13:13:33 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k85HDFYa009433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 5 Sep 2006 10:13:16 -0700 Received: from [10.0.1.2] (vpn-10-50-0-166.qualcomm.com [10.50.0.166]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k85HDDxB009612; Tue, 5 Sep 2006 10:13:14 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <44FDA62D.5080807@hxr.us> References: <00c201c6d0ff$23301770$640fa8c0@cis.neustar.com> <44FD9AFE.2000502@hxr.us> <44FD9FB7.8040709@cs.columbia.edu> <44FDA62D.5080807@hxr.us> Date: Tue, 5 Sep 2006 10:13:12 -0700 To: Andrew Newton , Henning Schulzrinne From: Ted Hardie Subject: Re: [Ecrit] faux privacy concerns Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: , Errors-To: ecrit-bounces@ietf.org At 12:30 PM -0400 9/5/06, Andrew Newton wrote: >Henning Schulzrinne wrote: >>Thus, a reasonable algorithm might be: >> >>(1) use TLS (server cert only) for LoST iff not in an emergency; if that fails for some reason, alert user and system operator (VSP); the bcp should suggest appropriate ways to determine ways to alert the operator >> >>(2) use plain-text LoST if the query is made at the time of the emergency call, given the trade-offs involved > >This is very reasonable, and sounds good to me. > >-andy > In point one, is the intent to alert the operator of the LoST server or the other parties (e.g. if the LoST server is derived from the access provider, are you notifying them or the VSP?) In point two, I agree that this is a good idea, and I think it reinforces the point made earlier by Brian. The terminal needs to know that a specific call is an emergency call. That will enable you to invoke this downgrade, as well as re-checking the mapping (at least Brian and I want to do this, and it should be possible, even if not mandated). regards, Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 05 13:20:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKebT-0004HA-0y; Tue, 05 Sep 2006 13:20:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKebS-0004H3-4C for ecrit@ietf.org; Tue, 05 Sep 2006 13:20:50 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKebQ-0000uM-U5 for ecrit@ietf.org; Tue, 05 Sep 2006 13:20:50 -0400 Received: from lion.cs.columbia.edu (IDENT:LN9TXCcbpzW9UhmCyL2iNokJmhZ8aOQi@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k85HKgGb001497 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 5 Sep 2006 13:20:43 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k85HKgg7015498 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 5 Sep 2006 13:20:42 -0400 Message-ID: <44FDB1E5.5080702@cs.columbia.edu> Date: Tue, 05 Sep 2006 13:20:37 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Ted Hardie Subject: Re: [Ecrit] faux privacy concerns References: <00c201c6d0ff$23301770$640fa8c0@cis.neustar.com> <44FD9AFE.2000502@hxr.us> <44FD9FB7.8040709@cs.columbia.edu> <44FDA62D.5080807@hxr.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter2.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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: , Errors-To: ecrit-bounces@ietf.org > In point one, is the intent to alert the operator of the LoST server or the other > parties (e.g. if the LoST server is derived from the access provider, are you > notifying them or the VSP?) > The operator of the LoST server contacted. Presumably, if the local resolver recurses, it would discover the error and alert its owner. I don't think returning such an address (only) via LoST is a good idea as it then leads to attacks where the bad guy interferes with TLS, redirects you to his rogue server, which contains the email address getlost@aol.com One possibility is a DNS entry, but there are probably better ideas. Including this *also* in the LoST response is probably helpful. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 06 15:50:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL3Pf-00063a-3n; Wed, 06 Sep 2006 15:50:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL3PP-0005pX-AU; Wed, 06 Sep 2006 15:50:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL3PO-0001Lk-Ve; Wed, 06 Sep 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id B312426E42; Wed, 6 Sep 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GL3PO-00029H-Gj; Wed, 06 Sep 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 06 Sep 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-lost-01.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : LoST: A Location-to-Service Translation Protocol Author(s) : T. Hardie, et al. Filename : draft-ietf-ecrit-lost-01.txt Pages : 52 Date : 2006-9-6 This document describes an XML-based protocol for mapping service identifiers and geospatial or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate PSAP for emergency services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ecrit-lost-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ecrit-lost-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-9-6124520.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-lost-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-lost-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-6124520.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --NextPart-- From ecrit-bounces@ietf.org Thu Sep 07 03:57:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLElG-0006mf-Lj; Thu, 07 Sep 2006 03:57:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLElF-0006ma-Fb for ecrit@ietf.org; Thu, 07 Sep 2006 03:57:21 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLElD-0000tL-Vb for ecrit@ietf.org; Thu, 07 Sep 2006 03:57:21 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id k877vGx3001119 for ; Thu, 7 Sep 2006 10:57:18 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Sep 2006 10:57:19 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Sep 2006 10:57:19 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Sep 2006 10:57:16 +0300 Message-ID: <29685ED45627A84ABE58DDFC37CC3B230340E366@trebe101.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Location information in emergency session initiation, need for time and accuracy? Thread-Index: AcbSUzw252Q4g3OhRYGg2BcbCcJ9iQ== From: To: X-OriginalArrivalTime: 07 Sep 2006 07:57:19.0500 (UTC) FILETIME=[3E3DE4C0:01C6D253] X-Spam-Score: 0.7 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Subject: [Ecrit] Location information in emergency session initiation, need for time and accuracy? 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="===============0971476132==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0971476132== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D253.3D9266A5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D253.3D9266A5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, When establishing an emergency session, a SIP UA may insert its location information into SIP INVITE as PIDF-LO object. The location information is used to route emergency session to correct PSAP and if the location is accurate enough, it can be used to advise the rescue team where needed. Delay of the emergency session establishment needs to be minimized and therefore UA may have to use old location information or provide it later during the call. Would it be beneficial to provide some kind of time stamp and accuracy information for the location? RFC 4119 (PIDF-LO) does not define accuracy of the location information. It defines timestamp for presence tuple, which indicates the time of the last change in the tuple. Maybe that timestamp is enough when geopriv is the only status element of the tuple but could there be other status elements in the future? I guess this would be relevant not just for emergency calls but also for location services in general, where time and accuracy of the location could be used for many purposes. How do you people see the relevancy of this kind of additional information for emergency calls? Would it be worth investigating how to extend PIDF-LO? There has been some discussion about this also in 3gpp but no real conclusions. Br, Vesa Hakkarainen ------_=_NextPart_001_01C6D253.3D9266A5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Location information in emergency session initiation, need for = time and accuracy?

Hi all,

When establishing an emergency session, = a SIP UA may insert its location information into SIP INVITE as PIDF-LO = object. The location information is used to route emergency session to = correct PSAP and if the location is accurate enough, it can be used to = advise the rescue team where needed. Delay of the emergency session = establishment needs to be minimized and therefore UA may have to use old = location information or provide it later during the call. Would it be = beneficial to provide some kind of time stamp and accuracy information = for the location? RFC 4119 (PIDF-LO) does not define accuracy of the = location information. It defines timestamp for presence tuple, which = indicates the time of the last change in the tuple. Maybe that timestamp = is enough when geopriv is the only status element of the tuple but could = there be other status elements in the future? I guess this would be = relevant not just for emergency calls but also for location services in = general, where time and accuracy of the location could be used for many = purposes.

How do you people see the relevancy of = this kind of additional information for emergency calls? Would it be = worth investigating how to extend PIDF-LO? There has been some = discussion about this also in 3gpp but no real conclusions.

Br,
        Vesa Hakkarainen

------_=_NextPart_001_01C6D253.3D9266A5-- --===============0971476132== 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 --===============0971476132==-- From ecrit-bounces@ietf.org Thu Sep 07 12:46:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLN0x-0006vs-Rn; Thu, 07 Sep 2006 12:46:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLN0v-0006uT-Ny for ecrit@ietf.org; Thu, 07 Sep 2006 12:46:05 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLN0t-0008Hd-BI for ecrit@ietf.org; Thu, 07 Sep 2006 12:46:05 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 07 Sep 2006 09:46:03 -0700 X-IronPort-AV: i="4.08,226,1154934000"; d="scan'208"; a="1852398475:sNHT32368092" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k87Gk2aM027931; Thu, 7 Sep 2006 09:46:02 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k87GjxwH003325; Thu, 7 Sep 2006 09:46:02 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Sep 2006 12:46:02 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.20.75]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Sep 2006 12:46:01 -0400 Message-Id: <4.3.2.7.2.20060907112817.03387570@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Sep 2006 11:46:00 -0500 To: , From: "James M. Polk" Subject: Re: [Ecrit] Location information in emergency session initiation, need for time and accuracy? In-Reply-To: <29685ED45627A84ABE58DDFC37CC3B230340E366@trebe101.NOE.Noki a.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 07 Sep 2006 16:46:01.0679 (UTC) FILETIME=[1A2245F0:01C6D29D] DKIM-Signature: a=rsa-sha1; q=dns; l=3281; t=1157647562; x=1158511562; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Ecrit]=20Location=20information=20in=20emergency=20session=0A=2 0=20initiation,=20need=20for=20time=20and=20accuracy?; X=v=3Dcisco.com=3B=20h=3Dh7vCYxsgrF3txyfM1FTfYjdhkWk=3D; b=NhdZVNMQd0tQSBjFTOwlzRIAm7MH2gBKlOBKhrIPgg5JrpWaVjRG1w+1ADvwWTKGOJu/jxIv XPq3j3Ym2hlXkq+LlH7Ltjq0Q3MsyYI+SnYpB2hG97YwIHPdg2Sr8i4f; Authentication-Results: sj-dkim-6.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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: , Errors-To: ecrit-bounces@ietf.org Vesa comments in-line At 10:57 AM 9/7/2006 +0300, vesa-matti.hakkarainen@nokia.com wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C6D253.3D9266A5" > >Hi all, > >When establishing an emergency session, a SIP UA may insert its location >information into SIP INVITE as PIDF-LO object. correct > The location information is used to route emergency session to correct > PSAP and if the location is accurate enough, "accurate enough"? What at this point would determine if it is accurate enough? >it can be used to advise the rescue team where needed. Delay of the >emergency session establishment needs to be minimized and therefore UA may >have to use old location information or provide it later during the call. The phone may not have moved in a while, so the old location info may still be good, as much as some believe "the world has gone mobile, most phones are not mobile, so it shouldn't be assumed every phone has moved since last receiving location information. >Would it be beneficial to provide some kind of time stamp and accuracy >information for the location? there is a timestamp (when the tuple was created), there is (on purpose) no accuracy. Please see the old archives within the Geopriv WG mailing list for this reasoning - that discussion was long and extensive, and seems to be rehashed every once in a while. >RFC 4119 (PIDF-LO) does not define accuracy of the location information. nope For example, take a typical phone off an Ethernet connection. How would accuracy be measured in this common scenario? Would it look like this: "I'm within 3 streets of Main st"? or "I'm within 3 cities of NYC"? Is the accuracy for Ethernet connected phones always the same? If not, what informs the phone it is different (since the phone is the generator of the PIDF-LO)? BTW - RFC3825 has resolution as part of its solution. This creates a GML defined Linear Ring, which is 100% accurate 100% of the time that the target is within that ring. This concept can be taken out to a cell tower's coverage area too (i.e. provide the polygon - regardless of shape - the target is within in the PIDF-LO). >It defines timestamp for presence tuple, which indicates the time of the >last change in the tuple. Maybe that timestamp is enough when geopriv is >the only status element of the tuple but could there be other status >elements in the future? I guess this would be relevant not just for >emergency calls but also for location services in general, where time and >accuracy of the location could be used for many purposes. > >How do you people see the relevancy of this kind of additional information >for emergency calls? Would it be worth investigating how to extend PIDF-LO? Geopriv chose not to have accuracy in the PIDF-LO, including the lack of uniformity and the lack of a means of measuring it >There has been some discussion about this also in 3gpp but no real >conclusions. > >Br, > Vesa Hakkarainen >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 07 13:24:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLNbm-0006T1-LU; Thu, 07 Sep 2006 13:24:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLNbl-0006St-10 for ecrit@ietf.org; Thu, 07 Sep 2006 13:24:09 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLNbk-0000N5-VV for ecrit@ietf.org; Thu, 07 Sep 2006 13:24:09 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GLNbg-0004UH-4p for ecrit@ietf.org; Thu, 07 Sep 2006 13:24:08 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Thu, 07 Sep 2006 13:23:52 -0400 id 015880C2.450055A9.000017E4 Message-ID: <450055A9.1040408@hxr.us> Date: Thu, 07 Sep 2006 13:23:53 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Ecrit] Location information in emergency session initiation, need for time and accuracy? References: <4.3.2.7.2.20060907112817.03387570@email.cisco.com> In-Reply-To: <4.3.2.7.2.20060907112817.03387570@email.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.8 (-) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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: , Errors-To: ecrit-bounces@ietf.org James M. Polk wrote: >> Would it be beneficial to provide some kind of time stamp and accuracy >> information for the location? > > there is a timestamp (when the tuple was created), there is (on purpose) > no accuracy. Please see the old archives within the Geopriv WG mailing > list for this reasoning - that discussion was long and extensive, and > seems to be rehashed every once in a while. Perhaps an Informational RFC on this specific topic is in order... one that discusses the problem and explains the consensus... and one that we can use to say "see RFC 5001". > BTW - RFC3825 has resolution as part of its solution. This creates a > GML defined Linear Ring, which is 100% accurate 100% of the time that > the target is within that ring. This concept can be taken out to a cell > tower's coverage area too (i.e. provide the polygon - regardless of > shape - the target is within in the PIDF-LO). It's good that you bring this up. I'm beginning to think that we need to tightly define the GML used for LoST. I don't know what a LoST server is suppose to do if a Linear Ring is bisected by multiple PSAP boundaries. Perhaps LoST input should only be a point and the service boundary should only be a polygon. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 07 13:44:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLNv5-0005l5-1c; Thu, 07 Sep 2006 13:44:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLNv3-0005kk-Sw for ecrit@ietf.org; Thu, 07 Sep 2006 13:44:05 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GLNv2-0002TO-KD for ecrit@ietf.org; Thu, 07 Sep 2006 13:44:05 -0400 Received: (qmail invoked by alias); 07 Sep 2006 17:44:02 -0000 Received: from p54985A1A.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.90.26] by mail.gmx.net (mp038) with SMTP; 07 Sep 2006 19:44:02 +0200 X-Authenticated: #29516787 Message-ID: <45005A61.4000609@gmx.net> Date: Thu, 07 Sep 2006 19:44:01 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: ECRIT , GEOPRIV Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [Ecrit] RFC 3825 & draft-ietf-geopriv-dhcp-civil-09.txt Implementation? 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: , Errors-To: ecrit-bounces@ietf.org Hi all, who has implemented RFC 3825 and/or draft-ietf-geopriv-dhcp-civil-09.txt? Is there open source code available? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 07 13:54:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLO4f-0001Mv-0z; Thu, 07 Sep 2006 13:54:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLO4d-0001Mq-TI for ecrit@ietf.org; Thu, 07 Sep 2006 13:53:59 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLO4c-0004AY-Lw for ecrit@ietf.org; Thu, 07 Sep 2006 13:53:59 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GLO4S-0008Ls-2c; Thu, 07 Sep 2006 12:53:48 -0500 From: "Brian Rosen" To: "'Andrew Newton'" , "'James M. Polk'" Subject: RE: [Ecrit] Location information in emergency session initiation, need for time and accuracy? Date: Thu, 7 Sep 2006 13:53:46 -0400 Message-ID: <017f01c6d2a6$96461fe0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcbSong2cmRensc+SZq5WyaeRlXpVAAAszZg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <450055A9.1040408@hxr.us> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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: , Errors-To: ecrit-bounces@ietf.org > Perhaps an Informational RFC on this specific topic is in order... one > that > discusses the problem and explains the consensus... and one that we can > use > to say "see RFC 5001". Agree. I nominate James Winterbottom as editor. If I can help (I don't know much) I will. > > > BTW - RFC3825 has resolution as part of its solution. This creates a > > GML defined Linear Ring, which is 100% accurate 100% of the time that > > the target is within that ring. This concept can be taken out to a cell > > tower's coverage area too (i.e. provide the polygon - regardless of > > shape - the target is within in the PIDF-LO). > > It's good that you bring this up. I'm beginning to think that we need to > tightly define the GML used for LoST. I don't know what a LoST server is > suppose to do if a Linear Ring is bisected by multiple PSAP boundaries. Agree we need text for this > Perhaps LoST input should only be a point and the service boundary should > only be a polygon. I would oppose this; I think the server should be free to accept a more complex shape, say a polygon, and intersect it with the boundaries. The service boundary has to at least be a SET of polyhedrons (3D polygons). I think it would be acceptable to limit to that. I think we could say that if the LoST server can't do anything better than point in polygon, it should take a location specified as a polygon and determine the centroid, and use that point to intersect with the service boundaries. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 07 14:02:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLOD4-0004HA-Ol; Thu, 07 Sep 2006 14:02:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLOD3-0004H5-SS for ecrit@ietf.org; Thu, 07 Sep 2006 14:02:41 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLOD2-0005Zc-M5 for ecrit@ietf.org; Thu, 07 Sep 2006 14:02:41 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Thu, 07 Sep 2006 14:02:34 -0400 id 01588434.45005EBA.00002060 Message-ID: <45005EBB.4050408@hxr.us> Date: Thu, 07 Sep 2006 14:02:35 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] Location information in emergency session initiation, need for time and accuracy? References: <017f01c6d2a6$96461fe0$640fa8c0@cis.neustar.com> In-Reply-To: <017f01c6d2a6$96461fe0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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: , Errors-To: ecrit-bounces@ietf.org Brian Rosen wrote: >> Perhaps an Informational RFC on this specific topic is in order... one >> that >> discusses the problem and explains the consensus... and one that we can >> use >> to say "see RFC 5001". > Agree. I nominate James Winterbottom as editor. If I can help (I don't > know much) I will. I was actually thinking of Mr. Polk. But whatever... >> Perhaps LoST input should only be a point and the service boundary should >> only be a polygon. > I would oppose this; I think the server should be free to accept a more > complex shape, say a polygon, and intersect it with the boundaries. > > The service boundary has to at least be a SET of polyhedrons (3D polygons). > I think it would be acceptable to limit to that. > > I think we could say that if the LoST server can't do anything better than > point in polygon, it should take a location specified as a polygon and > determine the centroid, and use that point to intersect with the service > boundaries. What you are asking might be ok for a LoST authoritative server. But just what is a LoST resolver suppose to do with a set of polyhedrons? And what happens when PSAP service boundaries bisect these areas? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 07 14:03:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLODe-0004fl-37; Thu, 07 Sep 2006 14:03:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLODc-0004fg-Co for ecrit@ietf.org; Thu, 07 Sep 2006 14:03:16 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLODb-0005gj-4d for ecrit@ietf.org; Thu, 07 Sep 2006 14:03:16 -0400 Received: from lion.cs.columbia.edu (IDENT:iQ+xX5uBEImWnNUoVKEBpS6HA9roAGQ5@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k87I38Gb028587 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 7 Sep 2006 14:03:08 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k87I37g7021122 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 7 Sep 2006 14:03:07 -0400 Message-ID: <45005ED6.1090803@cs.columbia.edu> Date: Thu, 07 Sep 2006 14:03:02 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] Location information in emergency session initiation, need for time and accuracy? References: <017f01c6d2a6$96461fe0$640fa8c0@cis.neustar.com> In-Reply-To: <017f01c6d2a6$96461fe0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter2.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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: , Errors-To: ecrit-bounces@ietf.org There are two issues: - service boundaries; I don't know why we need 3 dimensions as a requirement. I have no objection to allowing such shapes from a protocol perspective, although the use cases so far have been non-existent or fanciful. - point of query; having more than a point is both useless and dangerous. Otherwise, you have to be able to return all service providers that intersect that area, which means that the querier can specify a polygon encompassing the continental boundaries of all of North and South America and somehow get back every single PSAP in dozens of countries. This makes the backend system very much more complex, as ensuring that you indeed obtained all such information, with complete coverage, is rather difficult. You've just asked for a depth- or breadth-first exploration of the whole LoST server space. Kind of like asking for a recursive zone transfer for DNS... Thus, for the practical uses we care about, having a restriction to simple points-in-polygon avoids a rather dramatic increase in complexity, without impinging the legitimate uses. The client can compute that point at least as well as the server can and the client can decide whether it cares that different points in the polygon might have different service providers. I'm for simplicity and the 80/20 rule. Henning > The service boundary has to at least be a SET of polyhedrons (3D polygons). > I think it would be acceptable to limit to that. > > I think we could say that if the LoST server can't do anything better than > point in polygon, it should take a location specified as a polygon and > determine the centroid, and use that point to intersect with the service > boundaries. > > Brian > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 07 14:37:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLOkZ-0001oM-DF; Thu, 07 Sep 2006 14:37:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLOkY-0001oG-C2 for ecrit@ietf.org; Thu, 07 Sep 2006 14:37:18 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLOkX-00024g-0y for ecrit@ietf.org; Thu, 07 Sep 2006 14:37:18 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GLOkO-0003qk-IA; Thu, 07 Sep 2006 13:37:08 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Ecrit] Location information in emergency session initiation, need for time and accuracy? Date: Thu, 7 Sep 2006 14:37:11 -0400 Message-ID: <018501c6d2ac$a4807e10$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcbSp93Ze88uie4TSEeemG0Crc7k6wAAsBLQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <45005ED6.1090803@cs.columbia.edu> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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: , Errors-To: ecrit-bounces@ietf.org I thought I heard you giving use cases. As I recall, it was something like a university with a local EMS responder occupying some number of floors of a building. Agree that the important part is to allow it in the protocol. The way you use a polygon or polyhedron as a query location I think is called "best fit". If I have, to take an example, a set of tower faces, and set of service boundaries the server would do a best fit comparison of the tower face and the available service boundaries. Best fit is not all that hard to compute (intersection area). I don't want to force everyone to do this. I want to allow it. I never want to return a set of possibilities. You always get one. To me this is the same as not putting the LoST server in the position of choosing which of several reported locations to use to choose a route. The client chooses ONE. The same argument applies in reverse here: the LoST server never says "well, it could be this or it could be that", and lets the client try to figure out what to do. It always sends THE answer. The answer I would expect you would get if you send the boundary of the U.S. as the query location would be the same you would get if you sent a civic with only a country: some default PSAP. Or an error (but then what does the client do?). Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, September 07, 2006 2:03 PM > To: Brian Rosen > Cc: 'Andrew Newton'; 'James M. Polk'; ecrit@ietf.org > Subject: Re: [Ecrit] Location information in emergency session initiation, > need for time and accuracy? > > There are two issues: > > - service boundaries; I don't know why we need 3 dimensions as a > requirement. I have no objection to allowing such shapes from a protocol > perspective, although the use cases so far have been non-existent or > fanciful. > > - point of query; having more than a point is both useless and > dangerous. Otherwise, you have to be able to return all service > providers that intersect that area, which means that the querier can > specify a polygon encompassing the continental boundaries of all of > North and South America and somehow get back every single PSAP in dozens > of countries. This makes the backend system very much more complex, as > ensuring that you indeed obtained all such information, with complete > coverage, is rather difficult. You've just asked for a depth- or > breadth-first exploration of the whole LoST server space. Kind of like > asking for a recursive zone transfer for DNS... > > Thus, for the practical uses we care about, having a restriction to > simple points-in-polygon avoids a rather dramatic increase in > complexity, without impinging the legitimate uses. The client can > compute that point at least as well as the server can and the client can > decide whether it cares that different points in the polygon might have > different service providers. > > I'm for simplicity and the 80/20 rule. > > Henning > > > The service boundary has to at least be a SET of polyhedrons (3D > polygons). > > I think it would be acceptable to limit to that. > > > > I think we could say that if the LoST server can't do anything better > than > > point in polygon, it should take a location specified as a polygon and > > determine the centroid, and use that point to intersect with the service > > boundaries. > > > > Brian > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 07 14:39:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLOmd-0002zx-Hl; Thu, 07 Sep 2006 14:39:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLOmb-0002zj-On for ecrit@ietf.org; Thu, 07 Sep 2006 14:39:25 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLOma-0002bR-GZ for ecrit@ietf.org; Thu, 07 Sep 2006 14:39:25 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 07 Sep 2006 14:39:24 -0400 X-IronPort-AV: i="4.08,226,1154923200"; d="scan'208"; a="101204136:sNHT32320544" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k87IdOrh019714; Thu, 7 Sep 2006 14:39:24 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k87IdNuI026702; Thu, 7 Sep 2006 14:39:23 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Sep 2006 14:39:23 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.20.75]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Sep 2006 14:39:23 -0400 Message-Id: <4.3.2.7.2.20060907133706.03539b40@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Sep 2006 13:39:22 -0500 To: Andrew Newton From: "James M. Polk" Subject: Re: [Ecrit] Location information in emergency session initiation, need for time and accuracy? In-Reply-To: <450055A9.1040408@hxr.us> References: <4.3.2.7.2.20060907112817.03387570@email.cisco.com> <4.3.2.7.2.20060907112817.03387570@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 07 Sep 2006 18:39:23.0405 (UTC) FILETIME=[F0474BD0:01C6D2AC] DKIM-Signature: a=rsa-sha1; q=dns; l=833; t=1157654364; x=1158518364; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Ecrit]=20Location=20information=20in=20emergency=0A=20=20sessio n=09initiation,=20need=20for=20time=20and=20accuracy? |To:Andrew=20Newton=20; X=v=3Dcisco.com=3B=20h=3Dh7vCYxsgrF3txyfM1FTfYjdhkWk=3D; b=edRIRMhMhpq86D/WF38zNSuggCzDvIMOV/UwKg0jcQUO/zFdplc26jhFHvtImWZHJR8D1BeN DvLWCMJ0IIfjY0EzjSgQeQ7JeFsZl8l/u3BdHuOH50G8smBjc6fmLHNt; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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: , Errors-To: ecrit-bounces@ietf.org At 01:23 PM 9/7/2006 -0400, Andrew Newton wrote: >James M. Polk wrote: >>>Would it be beneficial to provide some kind of time stamp and accuracy >>>information for the location? >>there is a timestamp (when the tuple was created), there is (on purpose) >>no accuracy. Please see the old archives within the Geopriv WG mailing >>list for this reasoning - that discussion was long and extensive, and >>seems to be rehashed every once in a while. > >Perhaps an Informational RFC on this specific topic is in order... one >that discusses the problem and explains the consensus... and one that we >can use to say "see RFC 5001". I think this is a good idea. This topic keep coming up over and over again. Having an answer of "see RFC 5001" seems great as a complete answer to future inquiries of this >-andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 07 15:50:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLPtH-00063E-Kp; Thu, 07 Sep 2006 15:50:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLPtG-000639-Rf for ecrit@ietf.org; Thu, 07 Sep 2006 15:50:22 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLPtF-0007BW-KP for ecrit@ietf.org; Thu, 07 Sep 2006 15:50:22 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Thu, 07 Sep 2006 15:50:15 -0400 id 015880F6.450077F7.0000349E Message-ID: <450077F8.5060105@hxr.us> Date: Thu, 07 Sep 2006 15:50:16 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Location information in emergency session initiation, need for time and accuracy? References: <017f01c6d2a6$96461fe0$640fa8c0@cis.neustar.com> <45005ED6.1090803@cs.columbia.edu> In-Reply-To: <45005ED6.1090803@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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: , Errors-To: ecrit-bounces@ietf.org Henning Schulzrinne wrote: > There are two issues: > > - service boundaries; I don't know why we need 3 dimensions as a > requirement. I have no objection to allowing such shapes from a protocol > perspective, although the use cases so far have been non-existent or > fanciful. > > - point of query; having more than a point is both useless and > dangerous. Otherwise, you have to be able to return all service > providers that intersect that area, which means that the querier can > specify a polygon encompassing the continental boundaries of all of > North and South America and somehow get back every single PSAP in dozens > of countries. This makes the backend system very much more complex, as > ensuring that you indeed obtained all such information, with complete > coverage, is rather difficult. You've just asked for a depth- or > breadth-first exploration of the whole LoST server space. Kind of like > asking for a recursive zone transfer for DNS... I'm ok with an OPTIONAL altitude to accompany both the point in the query and the result service boundary. Apparently, it is quite common with Interstate junctions where the land beneath the overpass (the local road) is county/city jurisdiction but the actual overpass (40 ft above) is the jurisdiction of the state police. So I've been told. But allowing just any GML to appear in LoST seems to be a mistake. The protocol is the point of interoperability. So what if we did the following: o Do not restrict the protocol or schema to any particular shape. o Define a "basic GML profile" for LoST consisting of an X, Y, and optional Z for input and 2D polygon and optional Z for output. This is a MUST implement. o Create an error code to hand back to clients when a shape is not understood. Also instruct servers to return the basic profile in this case. o Require other shape usages to have a defined profile published as an RFC. This way we have a basic profile and a way forward to use additional profiles without a flag day. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 07 17:41:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLRcZ-0000rH-NW; Thu, 07 Sep 2006 17:41:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLRcY-0000pF-Hs for ecrit@ietf.org; Thu, 07 Sep 2006 17:41:14 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLRcX-0005t1-A3 for ecrit@ietf.org; Thu, 07 Sep 2006 17:41:14 -0400 Received: from lion.cs.columbia.edu (IDENT:lp9uQDirZzcFjhpoxYv7fN3BXUHHJ9/g@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k87LfBGb023953 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 7 Sep 2006 17:41:11 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k87LfBg7003062 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 7 Sep 2006 17:41:11 -0400 Message-ID: <450091F2.1090901@cs.columbia.edu> Date: Thu, 07 Sep 2006 17:41:06 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] Location information in emergency session initiation, need for time and accuracy? References: <017f01c6d2a6$96461fe0$640fa8c0@cis.neustar.com> <45005ED6.1090803@cs.columbia.edu> <450077F8.5060105@hxr.us> In-Reply-To: <450077F8.5060105@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter2.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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: , Errors-To: ecrit-bounces@ietf.org > I'm ok with an OPTIONAL altitude to accompany both the point in the > query and the result service boundary. Apparently, it is quite common > with Interstate junctions where the land beneath the overpass (the local > road) is county/city jurisdiction but the actual overpass (40 ft above) > is the jurisdiction of the state police. So I've been told. As far as I know, the altitude certainty, if any, in Phase II wireless would not not allow you to distinguish those. Plus, many overpasses only have a clearance of 12' or 15', so the difference is probably significantly below 40'. I very much doubt that any existing Phase II system can usefully distinguish those cases. > > But allowing just any GML to appear in LoST seems to be a mistake. The > protocol is the point of interoperability. So what if we did the > following: > > o Do not restrict the protocol or schema to any particular shape. > o Define a "basic GML profile" for LoST consisting of an X, Y, and > optional Z for input and 2D polygon and optional Z for output. This is > a MUST implement. > o Create an error code to hand back to clients when a shape is not > understood. Also instruct servers to return the basic profile in this > case. [Not sure what you mean by 'basic profile' here.] > o Require other shape usages to have a defined profile published as an RFC. That approach sounds reasonable. > > > This way we have a basic profile and a way forward to use additional > profiles without a flag day. It might also be nice to be able to discover the shape capability of the server, without having to do stepwise downgrading or trial-and-error. I think simply naming each such shape profile and returning the list of tokens would be sufficient. > > -andy > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 07 17:52:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLRmu-0005Sz-Hx; Thu, 07 Sep 2006 17:51:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLRms-0005St-NS for ecrit@ietf.org; Thu, 07 Sep 2006 17:51:54 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLRmn-0006kp-HI for ecrit@ietf.org; Thu, 07 Sep 2006 17:51:54 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Thu, 07 Sep 2006 17:51:32 -0400 id 0158843A.45009465.00004AD7 Message-ID: <45009465.2010403@hxr.us> Date: Thu, 07 Sep 2006 17:51:33 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Location information in emergency session initiation, need for time and accuracy? References: <017f01c6d2a6$96461fe0$640fa8c0@cis.neustar.com> <45005ED6.1090803@cs.columbia.edu> <450077F8.5060105@hxr.us> <450091F2.1090901@cs.columbia.edu> In-Reply-To: <450091F2.1090901@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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: , Errors-To: ecrit-bounces@ietf.org Henning Schulzrinne wrote: >> This way we have a basic profile and a way forward to use additional >> profiles without a flag day. > > It might also be nice to be able to discover the shape capability of the > server, without having to do stepwise downgrading or trial-and-error. I > think simply naming each such shape profile and returning the list of > tokens would be sufficient. But there is no single server. This is a series of servers: LoST resolvers, LoST forest guides, and LoST authoritative servers. Each could have a different capability set. In the end, what is important is the set of capabilities of a specific query path. I was trying not formulate a set reduction algorithm at every LoST hop, and specifically I don't know how it helps a proxy acting as a LoST seeker. I'm also not convinced that anybody will write any client code that will opt for anything other than the basic profile if the one they wish to use is rejected. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 07 17:55:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLRqH-0006T8-L4; Thu, 07 Sep 2006 17:55:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLRqG-0006Sa-PB for ecrit@ietf.org; Thu, 07 Sep 2006 17:55:24 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLRqF-0006xh-Ii for ecrit@ietf.org; Thu, 07 Sep 2006 17:55:24 -0400 Received: from lion.cs.columbia.edu (IDENT:+GkadxyK/gUGBVSTH1DZ2twO3s+8mMb7@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k87LtMGb028086 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 7 Sep 2006 17:55:22 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k87LtLg7004032 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 7 Sep 2006 17:55:21 -0400 Message-ID: <45009544.7040301@cs.columbia.edu> Date: Thu, 07 Sep 2006 17:55:16 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] Location information in emergency session initiation, need for time and accuracy? References: <017f01c6d2a6$96461fe0$640fa8c0@cis.neustar.com> <45005ED6.1090803@cs.columbia.edu> <450077F8.5060105@hxr.us> <450091F2.1090901@cs.columbia.edu> <45009465.2010403@hxr.us> In-Reply-To: <45009465.2010403@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter2.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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: , Errors-To: ecrit-bounces@ietf.org > But there is no single server. This is a series of servers: LoST > resolvers, LoST forest guides, and LoST authoritative servers. Each > could have a different capability set. Very good point. > > In the end, what is important is the set of capabilities of a specific > query path. I was trying not formulate a set reduction algorithm at > every LoST hop, and specifically I don't know how it helps a proxy > acting as a LoST seeker. > > I'm also not convinced that anybody will write any client code that will > opt for anything other than the basic profile if the one they wish to > use is rejected. I agree. Maybe some closed deployments will universally implement something beyond that. > > -andy > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 07 18:15:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLS9K-0005G7-Lo; Thu, 07 Sep 2006 18:15:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLS9J-0005CB-4k for ecrit@ietf.org; Thu, 07 Sep 2006 18:15:05 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLS9E-0000GN-PD for ecrit@ietf.org; Thu, 07 Sep 2006 18:15:05 -0400 Received: from lion.cs.columbia.edu (IDENT:sN7GqaS5rPqjtL+6eFyeVXw4EThPmsoV@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k87MEuGb002788 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 7 Sep 2006 18:14:57 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k87MEtg7005087 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 7 Sep 2006 18:14:56 -0400 Message-ID: <450099DA.4060600@cs.columbia.edu> Date: Thu, 07 Sep 2006 18:14:50 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] Location information in emergency session initiation, need for time and accuracy? References: <018501c6d2ac$a4807e10$640fa8c0@cis.neustar.com> In-Reply-To: <018501c6d2ac$a4807e10$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter1.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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: , Errors-To: ecrit-bounces@ietf.org Brian Rosen wrote: > I thought I heard you giving use cases. As I recall, it was something like > a university with a local EMS responder occupying some number of floors of a > building. If I said it, consider it in the "fanciful" category :-) > > Agree that the important part is to allow it in the protocol. > > The way you use a polygon or polyhedron as a query location I think is > called "best fit". If I have, to take an example, a set of tower faces, and > set of service boundaries the server would do a best fit comparison of the > tower face and the available service boundaries. Best fit is not all that > hard to compute (intersection area). I'm not a GIS expert, but I took a quick look at the capabilities of PostGIS, one of the better open-source geo-capable databases out there. http://postgis.refractions.net/docs/ch06.html describes the capabilities. I don't see anything that would make such a query easy or efficient, but I probably haven't looked hard enough. Unless common geo-databases support this functionality, I would argue that this is unlikely to be practical and likely to be of extremely limited use. In almost all cases, taking the centroid of the shape will yield the same result. Particularly given that the probability of you being in various points of the wireless polygon is distinctly non-uniform (as you get to the edges, relatively few people will be there, even for uniform population density, since you'll likely be associated with another tower that's stronger there), going for some overlap percentage is completely pointless accuracy - it's numerically better, but meaningless. > > I don't want to force everyone to do this. I want to allow it. Like Andy suggested, if there's a concrete need, another profile can be written later, once we better understand real "customer" demand and have some operational experience. In particular, we need to consider the impact on a *distributed* system, not think of LoST as one big server that has every PSAP in one database. > > I never want to return a set of possibilities. You always get one. To me > this is the same as not putting the LoST server in the position of choosing > which of several reported locations to use to choose a route. The client > chooses ONE. The same argument applies in reverse here: the LoST server > never says "well, it could be this or it could be that", and lets the client > try to figure out what to do. It always sends THE answer. > > The answer I would expect you would get if you send the boundary of the U.S. > as the query location would be the same you would get if you sent a civic > with only a country: some default PSAP. Or an error (but then what does the > client do?). This isn't quite the same. At least with civic, you general have a hierarchy that is one-to-many. If a poor LoST resolver gets a polygon that spans two states, handled at the county level by different LoST servers, it now needs to make two queries, to both states, and then what? Should this query be routed to the national or state PSAP, just because my coverage region spans a state boundary? Let's just say that the police and fire departments in NY and NJ are not going to be happy, given that roughly 20 million people live within a few miles of that boundary. The much better answer is to take the centroid of the coverage polygon and return one answer, in a county in one of the states. (The client should do that operation, as it is trivial and only the client might be able to do fancier versions, such as weighted centroids.) I'm sure you can special-case any of these, but you're now talking about writing custom code for each LoST server, rather than a database lookup. In this particular case, the custom code would need to be in the resolver, since it needs to make the decision about which state should be contacted. Once it forks the query, each state LoST server will just have to pretend that the query is wholly within its service area. The more of these cases, the more testing, corner cases and surprises. Not exactly what one might want in a system critical to emergency response. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 07 19:50:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLTdX-0008Vh-9p; Thu, 07 Sep 2006 19:50:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLTdW-0008VW-5m for ecrit@ietf.org; Thu, 07 Sep 2006 19:50:22 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLTcy-0005FD-VG for ecrit@ietf.org; Thu, 07 Sep 2006 19:49:50 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Sep 2006 18:49:48 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 07 Sep 2006 18:49:48 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Sep 2006 18:49:47 -0500 Message-ID: From: "Winterbottom, James" To: "Brian Rosen" , "Andrew Newton" , "James M. Polk" Date: Thu, 7 Sep 2006 18:49:46 -0500 Subject: RE: [Ecrit] Location information in emergency session initiation, need for time and accuracy? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 07 Sep 2006 23:49:47.0633 (UTC) FILETIME=[4D2EF610:01C6D2D8] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <017f01c6d2a6$96461fe0$640fa8c0@cis.neustar.com> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Location information in emergency session initiation, need for time and accuracy? Thread-Index: AcbSong2cmRensc+SZq5WyaeRlXpVAAAszZgAAyUOTA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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: , Errors-To: ecrit-bounces@ietf.org Okay, I don't mind picking this up. I agree with Brian, the whole purpose of the GeoShapes draft was to specify what shapes would be acceptable. These shapes should form the acceptable types for LoST. Cheers James =20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, 8 September 2006 3:54 AM > To: 'Andrew Newton'; 'James M. Polk' > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Location information in emergency session > initiation,need for time and accuracy? >=20 > > Perhaps an Informational RFC on this specific topic is in order... one > > that > > discusses the problem and explains the consensus... and one that we can > > use > > to say "see RFC 5001". > Agree. I nominate James Winterbottom as editor. If I can help (I don't > know much) I will. >=20 > > > > > BTW - RFC3825 has resolution as part of its solution. This creates a > > > GML defined Linear Ring, which is 100% accurate 100% of the time that > > > the target is within that ring. This concept can be taken out to a > cell > > > tower's coverage area too (i.e. provide the polygon - regardless of > > > shape - the target is within in the PIDF-LO). > > > > It's good that you bring this up. I'm beginning to think that we need > to > > tightly define the GML used for LoST. I don't know what a LoST server > is > > suppose to do if a Linear Ring is bisected by multiple PSAP boundaries. > Agree we need text for this >=20 > > Perhaps LoST input should only be a point and the service boundary > should > > only be a polygon. > I would oppose this; I think the server should be free to accept a more > complex shape, say a polygon, and intersect it with the boundaries. >=20 > The service boundary has to at least be a SET of polyhedrons (3D > polygons). > I think it would be acceptable to limit to that. >=20 > I think we could say that if the LoST server can't do anything better than > point in polygon, it should take a location specified as a polygon and > determine the centroid, and use that point to intersect with the service > boundaries. >=20 > Brian >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 07 20:31:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLUGe-0003Hm-7e; Thu, 07 Sep 2006 20:30:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLUGd-0003He-33 for ecrit@ietf.org; Thu, 07 Sep 2006 20:30:47 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLTXz-0004N0-4Y for ecrit@ietf.org; Thu, 07 Sep 2006 19:44:40 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Sep 2006 18:44:38 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 07 Sep 2006 18:44:37 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Sep 2006 18:44:37 -0500 Message-ID: From: "Winterbottom, James" To: "James M. Polk" , , Date: Thu, 7 Sep 2006 18:44:35 -0500 Subject: RE: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 07 Sep 2006 23:44:37.0070 (UTC) FILETIME=[9412CEE0:01C6D2D7] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <4.3.2.7.2.20060907112817.03387570@email.cisco.com> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy? Thread-Index: AcbSnUABDJMPdwpdSgCsZkQ3VnqthQAOTrOw X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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: , Errors-To: ecrit-bounces@ietf.org > BTW - RFC3825 has resolution as part of its solution. This creates a GML > defined Linear Ring, which is 100% accurate 100% of the time that the > target is within that ring. This concept can be taken out to a cell > tower's coverage area too (i.e. provide the polygon - regardless of shape > - Absolutely NOT POSSIBLE!! Conversion to and from the format specified by RFC-3825 can introduce large errors and it is not suitable around the lines of meridian. Please see PIDF-LO profile for a rationale of the mathematics. If I have a 100 metre Ethernet cable attached I am not going to be at the point specified by RFC-3825. Care to try again? RFC-3825 gives you a high confidence level, but its specification for uncertainty as it pertains to location representation and accuracy is not good. Until such time as the mechanism for specifying uncertainty is improved I would not recommend RFC-3825 for use in emergency applications. Cheers James ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 07 21:07:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLUpl-0001fq-Mx; Thu, 07 Sep 2006 21:07:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLUpk-0001fl-Um for ecrit@ietf.org; Thu, 07 Sep 2006 21:07:04 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLUpj-0001Br-OM for ecrit@ietf.org; Thu, 07 Sep 2006 21:07:04 -0400 Received: from [10.0.1.50] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Thu, 07 Sep 2006 21:06:37 -0400 id 0158843A.4500C21D.00006A88 In-Reply-To: <450099DA.4060600@cs.columbia.edu> References: <018501c6d2ac$a4807e10$640fa8c0@cis.neustar.com> <450099DA.4060600@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6C65226A-5DD4-42F0-BE43-8D4355BBB098@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Location information in emergency session initiation, need for time and accuracy? Date: Thu, 7 Sep 2006 21:06:41 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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: , Errors-To: ecrit-bounces@ietf.org On Sep 7, 2006, at 6:14 PM, Henning Schulzrinne wrote: > > > Brian Rosen wrote: >> I thought I heard you giving use cases. As I recall, it was >> something like >> a university with a local EMS responder occupying some number of >> floors of a >> building. > > If I said it, consider it in the "fanciful" category :-) I've got one... A well placed WiFi AP in Washington, D.C.'s Dupont Circle could probably have a service area of 5 separate countries... given that each embassy is sovereign soil. A cell tower or WiMAX AP could probably service 40 or 50 separate countries. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 07 21:09:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLUrx-0002Zx-HY; Thu, 07 Sep 2006 21:09:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLUrw-0002Zl-0N for ecrit@ietf.org; Thu, 07 Sep 2006 21:09:20 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLUrt-0001Sv-DW for ecrit@ietf.org; Thu, 07 Sep 2006 21:09:19 -0400 Received: from [10.0.1.50] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Thu, 07 Sep 2006 21:09:10 -0400 id 0158843A.4500C2B6.00006B1B In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <73EBD94D-474C-441E-A705-C32EFB903463@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Location information in emergency session initiation, need for time and accuracy? Date: Thu, 7 Sep 2006 21:09:15 -0400 To: "Winterbottom, James" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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: , Errors-To: ecrit-bounces@ietf.org On Sep 7, 2006, at 7:49 PM, Winterbottom, James wrote: > Okay, I don't mind picking this up. > > I agree with Brian, the whole purpose of the GeoShapes draft was to > specify what shapes would be acceptable. These shapes should form the > acceptable types for LoST. Can you please describe the LoST resolution algorithm for them? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 07 21:14:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLUwm-0004em-Mu; Thu, 07 Sep 2006 21:14:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLUwl-0004ee-1e for ecrit@ietf.org; Thu, 07 Sep 2006 21:14:19 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLUwe-0001j8-OR for ecrit@ietf.org; Thu, 07 Sep 2006 21:14:19 -0400 Received: from [192.168.0.41] (pool-141-153-175-20.mad.east.verizon.net [141.153.175.20]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k881E7Gl024416 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 7 Sep 2006 21:14:08 -0400 (EDT) In-Reply-To: <6C65226A-5DD4-42F0-BE43-8D4355BBB098@hxr.us> References: <018501c6d2ac$a4807e10$640fa8c0@cis.neustar.com> <450099DA.4060600@cs.columbia.edu> <6C65226A-5DD4-42F0-BE43-8D4355BBB098@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Location information in emergency session initiation, need for time and accuracy? Date: Thu, 7 Sep 2006 21:13:58 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.2) X-PerlMx-Spam: Gauge=XXII, Probability=22%, X-Seen-By filter1.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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: , Errors-To: ecrit-bounces@ietf.org I'm sure the Indian Embassy in DC has the civic address 2107 Massachusetts Ave NW Delhi-West India instead of the address reported by http://www.indianembassy.org/ 2107 Massachusetts Avenue, N.W., Washington D.C. USA - 20008 The latter must be a mistake. On Sep 7, 2006, at 9:06 PM, Andrew Newton wrote: > > On Sep 7, 2006, at 6:14 PM, Henning Schulzrinne wrote: > >> >> >> Brian Rosen wrote: >>> I thought I heard you giving use cases. As I recall, it was >>> something like >>> a university with a local EMS responder occupying some number of >>> floors of a >>> building. >> >> If I said it, consider it in the "fanciful" category :-) > > I've got one... > A well placed WiFi AP in Washington, D.C.'s Dupont Circle could > probably have a service area of 5 separate countries... given that > each embassy is sovereign soil. A cell tower or WiMAX AP could > probably service 40 or 50 separate countries. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 07 21:17:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLUzM-0004zu-85; Thu, 07 Sep 2006 21:17:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLUzK-0004yH-Oh for ecrit@ietf.org; Thu, 07 Sep 2006 21:16:58 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLUzI-000201-Gj for ecrit@ietf.org; Thu, 07 Sep 2006 21:16:58 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Sep 2006 20:16:56 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 07 Sep 2006 20:16:55 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Sep 2006 20:16:55 -0500 Message-ID: From: "Winterbottom, James" To: "Andrew Newton" Date: Thu, 7 Sep 2006 20:16:54 -0500 Subject: RE: [Ecrit] Location information in emergency session initiation, need for time and accuracy? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 08 Sep 2006 01:16:55.0850 (UTC) FILETIME=[797190A0:01C6D2E4] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <73EBD94D-474C-441E-A705-C32EFB903463@hxr.us> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Location information in emergency session initiation, need for time and accuracy? Thread-Index: AcbS42pB21T0f9fQQKKK4ILxpjJS3wAAD7gA X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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: , Errors-To: ecrit-bounces@ietf.org Andy, As I understand LoST, a LoST server has a database of shapes that define service boundaries. You take the shape specified, and see which boundary fits best. Anything other than a point may span more than one boundary. The problem is though, anything that measures location in geodetic form today measures it with a certain amount of uncertainty, this ranges from quite small, several metres, to quite large kms. When you define a shape, the host can reside anywhere with in it, and any point is equally likely to contain the host regardless of how the shape is defined. So picking an arbitrary point is a bad thing to do. LoST will need to support these shapes as the end-point may obtain its location from any number of sources, and it will have to do the best it can do to map them, and yes, sometimes it will get it wrong. > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Friday, 8 September 2006 11:09 AM > To: Winterbottom, James > Cc: Brian Rosen; James M. Polk; ecrit@ietf.org > Subject: Re: [Ecrit] Location information in emergency session > initiation,need for time and accuracy? >=20 >=20 > On Sep 7, 2006, at 7:49 PM, Winterbottom, James wrote: >=20 > > Okay, I don't mind picking this up. > > > > I agree with Brian, the whole purpose of the GeoShapes draft was to > > specify what shapes would be acceptable. These shapes should form the > > acceptable types for LoST. >=20 > Can you please describe the LoST resolution algorithm for them? >=20 > -andy ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 07 21:17:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLUzO-00052Y-Ev; Thu, 07 Sep 2006 21:17:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLUzN-00051B-2q for ecrit@ietf.org; Thu, 07 Sep 2006 21:17:01 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLUzJ-000207-PS for ecrit@ietf.org; Thu, 07 Sep 2006 21:17:01 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 07 Sep 2006 18:16:57 -0700 X-IronPort-AV: i="4.08,227,1154934000"; d="scan'208"; a="40505754:sNHT32476580" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k881Gv66009104; Thu, 7 Sep 2006 21:16:57 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k881GvdM001442; Thu, 7 Sep 2006 21:16:57 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Sep 2006 21:16:56 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.20.75]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Sep 2006 21:16:56 -0400 Message-Id: <4.3.2.7.2.20060907194222.035145d0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Sep 2006 20:16:55 -0500 To: "Winterbottom, James" From: "James M. Polk" Subject: RE: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy? In-Reply-To: References: <4.3.2.7.2.20060907112817.03387570@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 08 Sep 2006 01:16:56.0737 (UTC) FILETIME=[79F8E910:01C6D2E4] DKIM-Signature: a=rsa-sha1; q=dns; l=2639; t=1157678217; x=1158542217; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:RE=3A=20[Ecrit]=20Location=20information=20in=20emergency=0A=20=20sessio ninitiation,=20need=20for=20time=20and=20accuracy? |To:=22Winterbottom,=20James=22=20; X=v=3Dcisco.com=3B=20h=3Dk+PJ0FpAgHF2cb4YlBZFfsrsJwI=3D; b=J/7QfuJhh4/uaZUbY/V5jaDIjEucJP4dlAmQ7tlSKr6jKK6BmkNZAzaZ/88tZUIYP+6A/2/Q Ip8bMahNai9XjutGuhbe0jcntC62xMMxSVjmKJiE2OXIRgnLh8Jr/rPI; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 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: , Errors-To: ecrit-bounces@ietf.org At 06:44 PM 9/7/2006 -0500, Winterbottom, James wrote: > > BTW - RFC3825 has resolution as part of its solution. This creates a >GML > > defined Linear Ring, which is 100% accurate 100% of the time that the > > target is within that ring. This concept can be taken out to a cell > > tower's coverage area too (i.e. provide the polygon - regardless of >shape > > - > >Absolutely NOT POSSIBLE!! > >Conversion to and from the format specified by RFC-3825 can introduce >large errors and it is not suitable around the lines of meridian. "lines of meridian"? errr, how many meridian lines are there? You state this "fact" as if there are many - as if user will encounter them everywhere. North America is not NEAR one... Neither is your continent (Australia). Europe has only one, and and that's only in Britain. Asia doesn't have any meridian lines near them either... Now, how much of the world is 3825 unsuitable for? >Please >see PIDF-LO profile for a rationale of the mathematics. ... well... that draft has math in it, as does the appendix of 3825 3825 doesn't need rationale, it has numbers. pure and simple numbers. Every one of the examples in that appendix is an example of a linear ring. Every one is 100% accurate, 100% of the time. I'm sorry if you still do not understand the mechanism in 3825. >If I have a 100 metre Ethernet cable attached I am not going to be at >the point specified by RFC-3825. >Care to try again? dude, 3825 can measure a point to 2.62mm by 3.11mm at the equator (and smaller rectangles above or below the equator)... I'd say that's within a 100m cable ... *any* 100m cable *anywhere*. Care to tell me how it isn't? Here's a test: take a 100m cable and lay it out anywhere on the planet, and I can get not just one, but hundreds of 3825 LIs within the length of that 100m cable. Heck, you can probably point the cable straight up and I can still get a 3.11mm by 2.62mm position on the cable in 2D... >RFC-3825 gives you a high confidence level, but its specification for >uncertainty as it pertains to location representation and accuracy is >not good. James, James, James.... as I've said (Marc has too, and so has John S.) - "uncertainty" and "accuracy" are not precise enough to go into 3825, nor were they precise enough to go into 3693. BTW - the Geopriv WG seemed to agree too hehe >Until such time as the mechanism for specifying uncertainty is >improved I would not recommend RFC-3825 for use in emergency >applications. Fine, you go right ahead and don't recommend it. ;-) >Cheers >James _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 07 21:32:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLVDt-0003o9-Pr; Thu, 07 Sep 2006 21:32:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLVDt-0003o4-6u for ecrit@ietf.org; Thu, 07 Sep 2006 21:32:01 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLVDr-0003Xg-Sj for ecrit@ietf.org; Thu, 07 Sep 2006 21:32:01 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Sep 2006 20:31:59 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 07 Sep 2006 20:31:58 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Sep 2006 20:31:58 -0500 Message-ID: From: "Winterbottom, James" To: "James M. Polk" Date: Thu, 7 Sep 2006 20:31:56 -0500 Subject: RE: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 08 Sep 2006 01:31:58.0110 (UTC) FILETIME=[933B83E0:01C6D2E6] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <4.3.2.7.2.20060907194222.035145d0@email.cisco.com> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy? Thread-Index: AcbS5Hrr2ls/hpntTsadLgJj+EjmoAAAGbVQ X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f 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: , Errors-To: ecrit-bounces@ietf.org You seem to have forgotten about the equator, It goes straight through the middle of quite a number of countries. Which map are you looking at for the longitudinal meridian? I see it going through the middle of France, Spain and a big chunk of Africa, I guess these countries don't count? Nothing either you, Marc or JS has said has addressed the problems described in the appendix of the PIDF-LO profile draft. Until you can explain EXACLTY why these are not problems, and how you would perform the same conversions using RFC-3825 to end up with results that do not exhibit these errors. As we have continually pointed out, where these errors will creep in for other places is indeterminate, making it unsuitable. You could resolve this issue easily by modifying to the way in which the precision bits are interpreted to be inline with what JS proposed right back at the start of this debate. Doing this would resolve the issues with regards to format and error. Continuing to debate that accuracy, precision and confidence are 100% absolutely correct all the time is ludicrous and simply isn't worth the effort to continue. =20 > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Friday, 8 September 2006 11:17 AM > To: Winterbottom, James > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Location information in emergency sessioninitiation, > need for time and accuracy? >=20 > At 06:44 PM 9/7/2006 -0500, Winterbottom, James wrote: >=20 > > > BTW - RFC3825 has resolution as part of its solution. This creates a > >GML > > > defined Linear Ring, which is 100% accurate 100% of the time that the > > > target is within that ring. This concept can be taken out to a cell > > > tower's coverage area too (i.e. provide the polygon - regardless of > >shape > > > - > > > >Absolutely NOT POSSIBLE!! > > > >Conversion to and from the format specified by RFC-3825 can introduce > >large errors and it is not suitable around the lines of meridian. >=20 > "lines of meridian"? errr, how many meridian lines are there? You state > this "fact" as if there are many - as if user will encounter them > everywhere. >=20 > North America is not NEAR one... > Neither is your continent (Australia). > Europe has only one, and and that's only in Britain. > Asia doesn't have any meridian lines near them either... >=20 > Now, how much of the world is 3825 unsuitable for? >=20 > >Please > >see PIDF-LO profile for a rationale of the mathematics. >=20 > ... well... that draft has math in it, as does the appendix of 3825 >=20 > 3825 doesn't need rationale, it has numbers. pure and simple numbers. > Every > one of the examples in that appendix is an example of a linear ring. Every > one is 100% accurate, 100% of the time. >=20 > I'm sorry if you still do not understand the mechanism in 3825. >=20 >=20 > >If I have a 100 metre Ethernet cable attached I am not going to be at > >the point specified by RFC-3825. > >Care to try again? >=20 > dude, 3825 can measure a point to 2.62mm by 3.11mm at the equator (and > smaller rectangles above or below the equator)... I'd say that's within a > 100m cable ... *any* 100m cable *anywhere*. Care to tell me how it isn't? >=20 > Here's a test: take a 100m cable and lay it out anywhere on the planet, > and > I can get not just one, but hundreds of 3825 LIs within the length of that > 100m cable. Heck, you can probably point the cable straight up and I can > still get a 3.11mm by 2.62mm position on the cable in 2D... >=20 >=20 > >RFC-3825 gives you a high confidence level, but its specification for > >uncertainty as it pertains to location representation and accuracy is > >not good. >=20 > James, James, James.... as I've said (Marc has too, and so has John S.) - > "uncertainty" and "accuracy" are not precise enough to go into 3825, nor > were they precise enough to go into 3693. BTW - the Geopriv WG seemed to > agree too >=20 > hehe >=20 > >Until such time as the mechanism for specifying uncertainty is > >improved I would not recommend RFC-3825 for use in emergency > >applications. >=20 > Fine, you go right ahead and don't recommend it. >=20 > ;-) >=20 >=20 > >Cheers > >James ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 07 21:46:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLVRf-00017Z-GR; Thu, 07 Sep 2006 21:46:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLVRe-00017O-AI for ecrit@ietf.org; Thu, 07 Sep 2006 21:46:14 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLVRd-0004Zg-2N for ecrit@ietf.org; Thu, 07 Sep 2006 21:46:14 -0400 Received: from [192.168.0.41] (pool-141-153-175-20.mad.east.verizon.net [141.153.175.20]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k881jxGl025892 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 7 Sep 2006 21:46:00 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1BA03F82-36ED-4EC5-9D35-E051C86462A3@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Location information in emergency session initiation, need for time and accuracy? Date: Thu, 7 Sep 2006 21:45:54 -0400 To: "Winterbottom, James" X-Mailer: Apple Mail (2.752.2) X-PerlMx-Spam: Gauge=XXII, Probability=22%, X-Seen-By filter1.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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: , Errors-To: ecrit-bounces@ietf.org Unfortunately, due to its distributed nature, LoST service areas are *not* stored in a single database. Please see my NY/NJ example. Plus, we're not picking an "arbitrary" point, but rather the centroid of the region of uncertainty. Given that we don't know the precise probability distribution across the region of uncertainty, but know that it is not uniform, computing the likelihood of a "wrong" decision is probably fairly difficult. One would assume that, on average, the probability of being closer to the centroid is higher than towards the edge. At best, we might be able to say that there is some larger probability that the wrong PSAP will be contacted, but the details depend greatly on the shape of the service areas. You'd likely only get a divergence of centroid vs. max-area if the "wrong" area juts out into the main area and the centroid happens to fall on this "tip" of that jutting-out service area. For the much more common case of a (piecewise) linear coverage boundary and a circular area of uncertainty, the two methods will provide exactly the same answer. Thus, "errors" (quoted, since they are probabilistic) thus only occur: - if the coverage region spans many PSAP jurisdictions (unlikely, since large coverage areas occur mostly in rural areas with low population density) - if the centroid of the coverage area happens to fall into a highly "jagged" border line between two PSAPs Somehow, given that routing in Phase II wireless is typically done on tower/face only, this doesn't strike me as a major problem, compared to the complexity incurred in fixing it. Finally, if a client really cared about this, it can determine whether there is a problem by comparing the service area returned to its own area of uncertainty. Henning On Sep 7, 2006, at 9:16 PM, Winterbottom, James wrote: > Andy, > > As I understand LoST, a LoST server has a database of shapes that > define > service boundaries. You take the shape specified, and see which > boundary > fits best. Anything other than a point may span more than one > boundary. > The problem is though, anything that measures location in geodetic > form > today measures it with a certain amount of uncertainty, this ranges > from > quite small, several metres, to quite large kms. When you define a > shape, the host can reside anywhere with in it, and any point is > equally > likely to contain the host regardless of how the shape is defined. So > picking an arbitrary point is a bad thing to do. > > LoST will need to support these shapes as the end-point may obtain its > location from any number of sources, and it will have to do the > best it > can do to map them, and yes, sometimes it will get it wrong. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 07 21:53:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLVYd-0003kw-1u; Thu, 07 Sep 2006 21:53:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLVYb-0003kk-KT for ecrit@ietf.org; Thu, 07 Sep 2006 21:53:25 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLVYZ-0005C9-9u for ecrit@ietf.org; Thu, 07 Sep 2006 21:53:25 -0400 Received: from [10.0.1.50] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Thu, 07 Sep 2006 21:53:16 -0400 id 0158843B.4500CD0C.000072EF In-Reply-To: References: Mime-Version: 1.0 Message-Id: <2490F1EE-5290-4223-9AB0-3E09E4A29E50@hxr.us> From: Andrew Newton Subject: Re: [Ecrit] Location information in emergency session initiation, need for time and accuracy? Date: Thu, 7 Sep 2006 21:53:21 -0400 To: "Winterbottom, James" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 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: , Content-Type: multipart/mixed; boundary="===============0666991053==" Errors-To: ecrit-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============0666991053== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-29427-1157680397-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-29427-1157680397-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Sep 7, 2006, at 9:16 PM, Winterbottom, James wrote: > As I understand LoST, a LoST server has a database of shapes that > define > service boundaries. LoST is not 'A' server. It is a series of servers, some having varying roles. This system is essentially a distributed database. A resolution algorithm must specify much more than how a LoST authoritative server with a set of service boundaries is to resolve shapes. It MUST also describe how the LoST resolvers are to go about asking the various authoritative servers how to find that information, and how the LoST resolvers cache the information when shapes overlap multiple service boundaries. Once you move beyond a simple point, that becomes exceedingly complex. > You take the shape specified, and see which boundary > fits best. Anything other than a point may span more than one > boundary. > The problem is though, anything that measures location in geodetic > form > today measures it with a certain amount of uncertainty, this ranges > from > quite small, several metres, to quite large kms. When you define a > shape, the host can reside anywhere with in it, and any point is > equally > likely to contain the host regardless of how the shape is defined. So > picking an arbitrary point is a bad thing to do. What's to be done? Return four PSAP URIs and ask the user to pick one? And what is SIP proxy to do if it is acting as the LoST seeker? Randomly pick one of the 4? > LoST will need to support these shapes as the end-point may obtain its > location from any number of sources, and it will have to do the > best it > can do to map them, and yes, sometimes it will get it wrong. You are more than welcome to try and devise the LoST resolution algorithm for these shapes. The proposal I made would allow you to do that. -andy --=_zeke.ecotroph.net-29427-1157680397-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.53.3
On Sep 7, 2006, at 9:16= PM, Winterbottom, James wrote:

As= I understand LoST, a LoST server has a database of shapes that define

service boundaries.


LoST is not 'A' server.=A0 It is a series of servers, some having v= arying roles.=A0 This system is essentially a distributed database.=A0 A = resolution algorithm must specify much more than how a LoST authoritative= server with a set of service boundaries is to resolve shapes.=A0 It MUST= also describe how the LoST resolvers are to go about asking the various = authoritative servers how to find that information, and how the LoST reso= lvers cache the information when shapes overlap multiple service boundari= es.=A0 Once you move beyond a simple point, that becomes exceedingly comp= lex.

You take the shape specified, and see which boundary

<= P style=3D"margin: 0.0px 0.0px 0.0px 0.0px">fits best. Anything other than a = point may span more than one boundary.

The problem is though, anything that measures location = in geodetic form

= toda= y measures it with a certain amount of uncertainty, this ranges from

quite small, several metr= es, to quite large kms. When you define a

shape, the host can reside anywhere with in it, and = any point is equally

= likely to contain the host regardless of how the shape is defined. So

picking an arbitrary poi= nt is a bad thing to do.


What's to be done?=A0 Return four PSAP URIs= and ask the user to pick one?=A0 And what is SIP proxy to do if it is ac= ting as the LoST seeker?=A0 Randomly pick one of the 4?

LoST will need= to support these shapes as the end-point may obtain its

location from any number of sources, = and it will have to do the best it

can do to map them, and yes, sometimes it will get it wrong= .


You are more than welcome to try= and devise the LoST resolution algorithm for these shapes.=A0 The propos= al I made would allow you to do that.

-andy
--=_zeke.ecotroph.net-29427-1157680397-0001-2-- --===============0666991053== 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 --===============0666991053==-- From ecrit-bounces@ietf.org Thu Sep 07 21:53:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLVZ5-00041A-IZ; Thu, 07 Sep 2006 21:53:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLVZ4-0003zq-7C for ecrit@ietf.org; Thu, 07 Sep 2006 21:53:54 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLVZ2-0005FY-Tr for ecrit@ietf.org; Thu, 07 Sep 2006 21:53:54 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Sep 2006 20:53:52 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 07 Sep 2006 20:53:51 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Sep 2006 20:53:51 -0500 Message-ID: From: "Winterbottom, James" To: "Henning Schulzrinne" Date: Thu, 7 Sep 2006 20:53:49 -0500 Subject: RE: [Ecrit] Location information in emergency session initiation, need for time and accuracy? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 08 Sep 2006 01:53:51.0117 (UTC) FILETIME=[A1D87BD0:01C6D2E9] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <1BA03F82-36ED-4EC5-9D35-E051C86462A3@cs.columbia.edu> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Location information in emergency session initiation, need for time and accuracy? Thread-Index: AcbS6I1V04uKTR/sRK+4KpLYDjMsJAAAG1Sw X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 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: , Errors-To: ecrit-bounces@ietf.org Just closing on the last point there Henning. Most of the current Wireless Phase-II results in a 30% misrouting of calls, which is what prompted the latest version of J-STD-036 which introduces fast fix XY routing from the GMLC. I don't have figures for the new deployments yet, but the expected misrouting figure is likely to go right down. Solutions here will not be based on centroid, but certainly this does not have to be the case, and in our solution will likely not be. We have a chance to improve over existing cellular systems here it would be a pity if we didn't at least try. Cheers James > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, 8 September 2006 11:46 AM > To: Winterbottom, James > Cc: Andrew Newton; ecrit@ietf.org > Subject: Re: [Ecrit] Location information in emergency session initiation, > need for time and accuracy? >=20 > Unfortunately, due to its distributed nature, LoST service areas are > *not* stored in a single database. Please see my NY/NJ example. >=20 > Plus, we're not picking an "arbitrary" point, but rather the centroid > of the region of uncertainty. >=20 > Given that we don't know the precise probability distribution across > the region of uncertainty, but know that it is not uniform, computing > the likelihood of a "wrong" decision is probably fairly difficult. > One would assume that, on average, the probability of being closer to > the centroid is higher than towards the edge. >=20 > At best, we might be able to say that there is some larger > probability that the wrong PSAP will be contacted, but the details > depend greatly on the shape of the service areas. You'd likely only > get a divergence of centroid vs. max-area if the "wrong" area juts > out into the main area and the centroid happens to fall on this "tip" > of that jutting-out service area. For the much more common case of a > (piecewise) linear coverage boundary and a circular area of > uncertainty, the two methods will provide exactly the same answer. >=20 > Thus, "errors" (quoted, since they are probabilistic) thus only occur: >=20 > - if the coverage region spans many PSAP jurisdictions (unlikely, > since large coverage areas occur mostly in rural areas with low > population density) >=20 > - if the centroid of the coverage area happens to fall into a highly > "jagged" border line between two PSAPs >=20 > Somehow, given that routing in Phase II wireless is typically done on > tower/face only, this doesn't strike me as a major problem, compared > to the complexity incurred in fixing it. >=20 > Finally, if a client really cared about this, it can determine > whether there is a problem by comparing the service area returned to > its own area of uncertainty. >=20 > Henning >=20 >=20 > On Sep 7, 2006, at 9:16 PM, Winterbottom, James wrote: >=20 > > Andy, > > > > As I understand LoST, a LoST server has a database of shapes that > > define > > service boundaries. You take the shape specified, and see which > > boundary > > fits best. Anything other than a point may span more than one > > boundary. > > The problem is though, anything that measures location in geodetic > > form > > today measures it with a certain amount of uncertainty, this ranges > > from > > quite small, several metres, to quite large kms. When you define a > > shape, the host can reside anywhere with in it, and any point is > > equally > > likely to contain the host regardless of how the shape is defined. So > > picking an arbitrary point is a bad thing to do. > > > > LoST will need to support these shapes as the end-point may obtain its > > location from any number of sources, and it will have to do the > > best it > > can do to map them, and yes, sometimes it will get it wrong. > > >=20 ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 07 22:04:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLVj8-00019e-Pj; Thu, 07 Sep 2006 22:04:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLVj6-00019Z-So for ecrit@ietf.org; Thu, 07 Sep 2006 22:04:16 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLVj6-0006aK-Cu for ecrit@ietf.org; Thu, 07 Sep 2006 22:04:16 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Sep 2006 21:04:16 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 07 Sep 2006 21:04:15 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Sep 2006 21:04:14 -0500 Message-ID: From: "Winterbottom, James" To: "Andrew Newton" Date: Thu, 7 Sep 2006 21:04:12 -0500 Subject: RE: [Ecrit] Location information in emergency session initiation, need for time and accuracy? MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 08 Sep 2006 02:04:14.0439 (UTC) FILETIME=[155FDF70:01C6D2EB] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <2490F1EE-5290-4223-9AB0-3E09E4A29E50@hxr.us> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Location information in emergency session initiation, need for time and accuracy? Thread-Index: AcbS6ZK+cPqZBG5AQO646yqPIHDAIwAAHGfw X-Spam-Score: 0.1 (/) X-Scan-Signature: b612707e1a3f67df80ae89cdab1ba981 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: , Content-Type: multipart/mixed; boundary="===============0854675118==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0854675118== Content-Type: multipart/alternative; boundary="--=_NextPart_ST_21_04_15_Thursday_September_07_2006_22311" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ----=_NextPart_ST_21_04_15_Thursday_September_07_2006_22311 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So the user gets an arcband because his location was determined from a timing advance measurement. In its base form, this is defined as lat, long, radius inner, radius outer, offset angle and inclusion angle. =20 What are you expecting each thing in the communication path to do? =20 I understand that the resolver problem is complex, but a point restriction is also a pretty serious shortcoming. =20 =20 =20 ________________________________ From: Andrew Newton [mailto:andy@hxr.us]=20 Sent: Friday, 8 September 2006 11:53 AM To: Winterbottom, James Cc: Brian Rosen; James M. Polk; ecrit@ietf.org Subject: Re: [Ecrit] Location information in emergency session initiation,need for time and accuracy? =20 =20 On Sep 7, 2006, at 9:16 PM, Winterbottom, James wrote: As I understand LoST, a LoST server has a database of shapes that define service boundaries.=20 =20 LoST is not 'A' server. It is a series of servers, some having varying roles. This system is essentially a distributed database. A resolution algorithm must specify much more than how a LoST authoritative server with a set of service boundaries is to resolve shapes. It MUST also describe how the LoST resolvers are to go about asking the various authoritative servers how to find that information, and how the LoST resolvers cache the information when shapes overlap multiple service boundaries. Once you move beyond a simple point, that becomes exceedingly complex. You take the shape specified, and see which boundary fits best. Anything other than a point may span more than one boundary. The problem is though, anything that measures location in geodetic form today measures it with a certain amount of uncertainty, this ranges from quite small, several metres, to quite large kms. When you define a shape, the host can reside anywhere with in it, and any point is equally likely to contain the host regardless of how the shape is defined. So picking an arbitrary point is a bad thing to do. =20 What's to be done? Return four PSAP URIs and ask the user to pick one? And what is SIP proxy to do if it is acting as the LoST seeker? Randomly pick one of the 4? LoST will need to support these shapes as the end-point may obtain its location from any number of sources, and it will have to do the best it can do to map them, and yes, sometimes it will get it wrong. =20 You are more than welcome to try and devise the LoST resolution algorithm for these shapes. The proposal I made would allow you to do that. =20 -andy ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] ----=_NextPart_ST_21_04_15_Thursday_September_07_2006_22311 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

So the user gets an arcband because hi= s location was determined from a timing advance measurement.

In its base form, this is defined as l= at, long, radius inner, radius outer, offset angle and inclusion angle.

 

What are you expecting each thing in t= he communication path to do?

 

I understand that the resolver problem= is complex, but a point restriction is also a pretty serious shortcoming.=

 

 

 

From:= Andrew Newton [mailto:andy@hxr.us]
Sent: Friday, 8 September 20= 06 11:53 AM
To: Winterbottom, James
Cc: Brian Rosen; James M. Po= lk; ecrit@ietf.org
Subject: Re: [Ecrit] Locatio= n information in emergency session initiation,need for time and accuracy?

 

 

On Sep 7, 2006, at 9:16 PM, Winterbottom, James wrote:



As I understand LoST, a LoS= T server has a database of shapes that define

service boundaries. =

 

LoST is not 'A' server.  It is a series of servers, some havin= g varying roles.  This system is essentially a distributed database.&nbs= p; A resolution algorithm must specify much more than how a LoST authoritative server with a set of service boundaries is to resolve shapes.  It MUST also describe how the LoST resolvers are to go about asking the various authoritative servers how to find that information, and how the LoST resolv= ers cache the information when shapes overlap multiple service boundaries. = ; Once you move beyond a simple point, that becomes exceedingly complex.=



You take the shape specifie= d, and see which boundary

fits best. Anything other t= han a point may span more than one boundary.

The problem is though, anyt= hing that measures location in geodetic form

today measures it with a ce= rtain amount of uncertainty, this ranges from

quite small, several metres= , to quite large kms. When you define a

shape, the host can reside anywhere with in it, and any point is equally

likely to contain the host regardless of how the shape is defined. So

picking an arbitrary point = is a bad thing to do.

 

What's to be done?  Return four PSAP URIs and ask the user to = pick one?  And what is SIP proxy to do if it is acting as the LoST seeker?  Randomly pick one of the 4?



LoST will need to support t= hese shapes as the end-point may obtain its

location from any number of sources, and it will have to do the best it

can do to map them, and yes= , sometimes it will get it wrong.

 

You are more than welcome to try and devise the LoST resolution algorithm for these shapes.  The proposal I made would allow you to do that.

 

-andy


-----------------------------------------------------------------------= -------------------------
This message is for the designated recipient o= nly and may
contain privileged, proprietary, or otherwise private inform= ation.
If you have received it in error, please notify the sender
i= mmediately and delete the original. Any unauthorized use of
this email = is prohibited.
---------------------------------------------------------= ---------------------------------------
[mf2] ----=_NextPart_ST_21_04_15_Thursday_September_07_2006_22311-- --===============0854675118== 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 --===============0854675118==-- From ecrit-bounces@ietf.org Thu Sep 07 22:08:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLVmi-0002Kd-RG; Thu, 07 Sep 2006 22:08:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLVmg-0002JX-Rm for ecrit@ietf.org; Thu, 07 Sep 2006 22:07:59 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLVmf-0006oX-L5 for ecrit@ietf.org; Thu, 07 Sep 2006 22:07:58 -0400 Received: from [192.168.0.41] (pool-141-153-175-20.mad.east.verizon.net [141.153.175.20]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k8827pGl026895 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 7 Sep 2006 22:07:52 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Location information in emergency session initiation, need for time and accuracy? Date: Thu, 7 Sep 2006 22:07:45 -0400 To: "Winterbottom, James" X-Mailer: Apple Mail (2.752.2) X-PerlMx-Spam: Gauge=XXII, Probability=22%, X-Seen-By filter1.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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: , Errors-To: ecrit-bounces@ietf.org Glad to hear that they'll introduce fast-fix routing. This presumably reduces the coverage region to much smaller areas, making the problem that much less likely, regardless of how the PSAP is picked. I very much doubt that cell/face with max-area would have improved the routing accuracy above 70%, so this seems largely orthogonal. On Sep 7, 2006, at 9:53 PM, Winterbottom, James wrote: > Just closing on the last point there Henning. > Most of the current Wireless Phase-II results in a 30% misrouting of > calls, which is what prompted the latest version of J-STD-036 which > introduces fast fix XY routing from the GMLC. I don't have figures for > the new deployments yet, but the expected misrouting figure is > likely to > go right down. > > Solutions here will not be based on centroid, but certainly this does > not have to be the case, and in our solution will likely not be. > > We have a chance to improve over existing cellular systems here it > would > be a pity if we didn't at least try. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 07 22:10:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLVpN-0003TB-6k; Thu, 07 Sep 2006 22:10:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLVpM-0003T6-DC for ecrit@ietf.org; Thu, 07 Sep 2006 22:10:44 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLVpL-00075S-6i for ecrit@ietf.org; Thu, 07 Sep 2006 22:10:44 -0400 Received: from [192.168.0.41] (pool-141-153-175-20.mad.east.verizon.net [141.153.175.20]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k882AcGl027040 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 7 Sep 2006 22:10:39 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <73496AC7-5224-47A0-988B-EB2F54E4052A@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Location information in emergency session initiation, need for time and accuracy? Date: Thu, 7 Sep 2006 22:10:31 -0400 To: "Winterbottom, James" X-Mailer: Apple Mail (2.752.2) X-PerlMx-Spam: Gauge=XXII, Probability=22%, X-Seen-By filter2.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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: , Errors-To: ecrit-bounces@ietf.org Easy: Either the client or the first server computes the centroid of the arcband. If the area of the arcband is large (square miles), it will have large misroute probabilities, regardless of how the match is computed. On Sep 7, 2006, at 10:04 PM, Winterbottom, James wrote: > So the user gets an arcband because his location was determined > from a timing advance measurement. > > In its base form, this is defined as lat, long, radius inner, > radius outer, offset angle and inclusion angle. > > > > What are you expecting each thing in the communication path to do? > > > > I understand that the resolver problem is complex, but a point > restriction is also a pretty serious shortcoming. > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 07 22:48:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLWPM-0002Y9-3K; Thu, 07 Sep 2006 22:47:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLWPK-0002Uk-HP for ecrit@ietf.org; Thu, 07 Sep 2006 22:47:54 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLWPJ-0002oP-8Q for ecrit@ietf.org; Thu, 07 Sep 2006 22:47:54 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Sep 2006 21:47:52 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 07 Sep 2006 21:47:51 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Sep 2006 21:47:51 -0500 Message-ID: From: "Thomson, Martin" To: "Henning Schulzrinne" , "Winterbottom, James" Date: Thu, 7 Sep 2006 21:47:49 -0500 Subject: RE: [Ecrit] Location information in emergency session initiation, need for time and accuracy? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 08 Sep 2006 02:47:51.0393 (UTC) FILETIME=[2D335D10:01C6D2F1] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <73496AC7-5224-47A0-988B-EB2F54E4052A@cs.columbia.edu> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Location information in emergency session initiation, need for time and accuracy? Thread-Index: AcbS7DbzoaRRdakbR0uSy8BLZvq7VwAAL5Xg X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 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: , Errors-To: ecrit-bounces@ietf.org If we provide the additional information to the LoST server (I am not talking about the system, just one specific node in that network), then the server can make the centroid calculation. This gives the LoST server the option of taking uncertainty into consideration. When you pick a point, there is a significant chance that you pick the wrong point. After all the centre of a circle that represents a Cellular tower is probably the spot where you _wont_ find the target. I showed a picture before, and without a picture, it's hard to illustrate, so refer to my example on the geopriv list: http://www1.ietf.org/mail-archive/web/geopriv/current/msg01552.html If the device performs a conversion, this information is lost. This information could be used to reduce the chance of misroutes. I'd prefer that the target provides the same information that it receives from the LIS to the LoST network. If the LoST server wants to do a simple conversion to a point, then it assumes the responsibility for the loss of information. Cheers, Martin -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Friday, 8 September 2006 12:11 PM To: Winterbottom, James Cc: ecrit@ietf.org Subject: Re: [Ecrit] Location information in emergency session initiation,need for time and accuracy? Easy: Either the client or the first server computes the centroid of =20 the arcband. If the area of the arcband is large (square miles), it will have =20 large misroute probabilities, regardless of how the match is computed. On Sep 7, 2006, at 10:04 PM, Winterbottom, James wrote: > So the user gets an arcband because his location was determined =20 > from a timing advance measurement. > > In its base form, this is defined as lat, long, radius inner, =20 > radius outer, offset angle and inclusion angle. > > > > What are you expecting each thing in the communication path to do? > > > > I understand that the resolver problem is complex, but a point =20 > restriction is also a pretty serious shortcoming. > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 07 22:58:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLWZ4-0006rB-55; Thu, 07 Sep 2006 22:57:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLWZ3-0006r6-56 for ecrit@ietf.org; Thu, 07 Sep 2006 22:57:57 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLWZ1-0003vJ-Tr for ecrit@ietf.org; Thu, 07 Sep 2006 22:57:57 -0400 Received: from [10.0.1.50] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Thu, 07 Sep 2006 22:57:39 -0400 id 0158843E.4500DC23.00007D3A In-Reply-To: References: Mime-Version: 1.0 Message-Id: <58F7020E-3017-4013-AF68-824FEBA96483@hxr.us> From: Andrew Newton Subject: Re: [Ecrit] Location information in emergency session initiation, need for time and accuracy? Date: Thu, 7 Sep 2006 22:57:44 -0400 To: "Winterbottom, James" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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: , Content-Type: multipart/mixed; boundary="===============0537601782==" Errors-To: ecrit-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============0537601782== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-32062-1157684269-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-32062-1157684269-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Sep 7, 2006, at 10:04 PM, Winterbottom, James wrote: > I understand that the resolver problem is complex, but a point > restriction is also a pretty serious shortcoming. Regardless of the complexity, the resolver algorithm MUST be specified. Without that specification, the restriction is much, much worse than a point restriction. As I said before, you are more than welcome to work on this specification. And my proposal will allow you to introduce that specification into the LoST system without a flag day, and without your having to have it finished when LoST is ratified. It will even let you come back later on and revise your specification. Do you find this objectionable? -andy --=_zeke.ecotroph.net-32062-1157684269-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.53.3
On Sep 7, 2006, at 10:0= 4 PM, Winterbottom, James wrote:

I understand that the resolver problem is compl= ex, but a point restriction is also a pretty serious shortcoming.<= /SPAN>

Regardless of the complex= ity, the resolver algorithm MUST be specified.=A0 Without that specificat= ion, the restriction is much, much worse than a point restriction.=A0 As = I said before, you are more than welcome to work on this specification.=A0= And my proposal will allow you to introduce that specification into the = LoST system without a flag day, and without your having to have it finish= ed when LoST is ratified.=A0 It will even let you come back later on and = revise your specification.=A0 Do you find this objectionable?
<= BR class=3D"khtml-block-placeholder">
-andy
--=_zeke.ecotroph.net-32062-1157684269-0001-2-- --===============0537601782== 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 --===============0537601782==-- From ecrit-bounces@ietf.org Fri Sep 08 03:34:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLas0-00075y-UC; Fri, 08 Sep 2006 03:33:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLarz-00075n-AH for ecrit@ietf.org; Fri, 08 Sep 2006 03:33:47 -0400 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLaru-0001rv-TQ for ecrit@ietf.org; Fri, 08 Sep 2006 03:33:47 -0400 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTPœ id k887XZhg006687Fri, 8 Sep 2006 07:33:35 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1GLarn-00038V-00; Fri, 08 Sep 2006 08:33:35 +0100 Date: Fri, 8 Sep 2006 08:33:35 +0100 From: "Clive D.W. Feather" To: "James M. Polk" Subject: Re: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy? Message-ID: <20060908073335.GA9691@finch-staff-1.thus.net> References: <4.3.2.7.2.20060907112817.03387570@email.cisco.com> <4.3.2.7.2.20060907194222.035145d0@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20060907194222.035145d0@email.cisco.com> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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: , Errors-To: ecrit-bounces@ietf.org James M. Polk said: > "lines of meridian"? errr, how many meridian lines are there? An infinite number. A "line of meridian" is the set of points with the same longitude (a semi-circle) *or* the union of two such sets that form a planar circle. > You state > this "fact" as if there are many - as if user will encounter them > everywhere. They're unavoidable. > Europe has only one, and and that's only in Britain. If you're talking about the Prime Meridian, then this passes through the land masses of three European countries, and I haven't attempted to verify whether it crosses territorial claims of any others - it passes between parts of at least two other countries. > 3825 doesn't need rationale, it has numbers. pure and simple numbers. Every > one of the examples in that appendix is an example of a linear ring. Every > one is 100% accurate, 100% of the time. > > I'm sorry if you still do not understand the mechanism in 3825. 3825 does not explain in normative text: - that the encoding is twos complement (sign and magnitude would probably be more sensible in this context); - how to construct a rectangle that crosses the Prime Meridian or the equator; - what is the meaning of a value that is, or includes cases, outside the +/-90 or +/-180 range (the SHOULD be in range rule doesn't cut it, here). It's also a bad encoding because it requires boundaries to be aligned to units of the same size as the boundary. For example, if I want to define an area 2 degrees high, I have to use boundaries that are even numbers of degrees; there's no way to encode a square, 2 degrees on a side, centred on 52N 2W. In fact, the *only* encoding I can do for an area centred on that point is a rectangle 4 degrees east-west and 8 degrees north-south. For *any* point, there's only one rectangle with that point at its centre that can be encoded. >> If I have a 100 metre Ethernet cable attached I am not going to be at >> the point specified by RFC-3825. >> Care to try again? > dude, 3825 can measure a point to 2.62mm by 3.11mm at the equator (and > smaller rectangles above or below the equator)... I'd say that's within a > 100m cable ... *any* 100m cable *anywhere*. Care to tell me how it isn't? Completely missing the point. How do I specify "I'm within 100m of the termination point of the cable"? There's no 3825 LI for this, and any LI that includes all of this circle will include some random area around it. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 08 07:28:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLeWX-0002rk-0c; Fri, 08 Sep 2006 07:27:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLeWV-0002re-TB for ecrit@ietf.org; Fri, 08 Sep 2006 07:27:51 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLeWS-0000M6-AW for ecrit@ietf.org; Fri, 08 Sep 2006 07:27:51 -0400 Received: from [10.0.1.50] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Fri, 08 Sep 2006 07:27:33 -0400 id 01588176.450153A5.00006164 In-Reply-To: References: Mime-Version: 1.0 Message-Id: <22A9A973-7DDA-491F-8359-EBD83438B9D0@hxr.us> From: Andrew Newton Subject: Re: [Ecrit] Location information in emergency session initiation, need for time and accuracy? Date: Fri, 8 Sep 2006 07:27:36 -0400 To: "Thomson, Martin" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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: , Content-Type: multipart/mixed; boundary="===============0082408185==" Errors-To: ecrit-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============0082408185== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-24936-1157714862-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-24936-1157714862-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Sep 7, 2006, at 10:47 PM, Thomson, Martin wrote: > If we provide the additional information to the LoST server (I am not > talking about the system, just one specific node in that network), > then > the server can make the centroid calculation. This gives the LoST > server the option of taking uncertainty into consideration. Ok. How do I know which server to ask? -andy --=_zeke.ecotroph.net-24936-1157714862-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.53.3
On Sep 7, 2006, at 10:4= 7 PM, Thomson, Martin wrote:

<= FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">If we= provide the additional information to the LoST server (I am not

talking about the system, jus= t one specific node in that network), then

the server can make the centroid calculation.=A0 This gives the LoST

=

server the option of taking unc= ertainty into consideration.


Ok.=A0= How do I know which server to ask?

-andy
--=_zeke.ecotroph.net-24936-1157714862-0001-2-- --===============0082408185== 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 --===============0082408185==-- From ecrit-bounces@ietf.org Fri Sep 08 08:14:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLfEo-0005AX-U5; Fri, 08 Sep 2006 08:13:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLfEo-0005AS-64 for ecrit@ietf.org; Fri, 08 Sep 2006 08:13:38 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLfEm-0006n3-Vj for ecrit@ietf.org; Fri, 08 Sep 2006 08:13:38 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GLfEZ-0006oH-Cc; Fri, 08 Sep 2006 07:13:30 -0500 From: "Brian Rosen" To: "'Andrew Newton'" , "'Thomson, Martin'" Subject: RE: [Ecrit] Location information in emergency session initiation, need for time and accuracy? Date: Fri, 8 Sep 2006 08:13:21 -0400 Message-ID: <02f301c6d340$3410ed10$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcbTOfCcfRpZq0LwTruTSGi90ME9GwABXrOg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <22A9A973-7DDA-491F-8359-EBD83438B9D0@hxr.us> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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: , Errors-To: ecrit-bounces@ietf.org I am not an expert here. James may have to correct me, but I believe you use "best fit", which I believe is max area of overlap. With points and polygons, you find the polygon which contains the point. With polygons (or other area figures like circles) and polygons, you intersect the location polygons (areas) with each candidate service boundaries and choose the one that has the largest intersection area. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 08 08:18:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLfJ1-0006iq-BJ; Fri, 08 Sep 2006 08:17:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLfIz-0006id-Db for ecrit@ietf.org; Fri, 08 Sep 2006 08:17:57 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLfIy-0007qR-4b for ecrit@ietf.org; Fri, 08 Sep 2006 08:17:57 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 07:17:55 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Fri, 08 Sep 2006 07:17:55 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 07:17:54 -0500 Message-ID: From: "Winterbottom, James" To: "Brian Rosen" , "Andrew Newton" , "Thomson, Martin" Date: Fri, 8 Sep 2006 07:17:53 -0500 Subject: RE: [Ecrit] Location information in emergency session initiation, need for time and accuracy? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 08 Sep 2006 12:17:54.0640 (UTC) FILETIME=[CFECAD00:01C6D340] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <02f301c6d340$3410ed10$640fa8c0@cis.neustar.com> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Location information in emergency session initiation, need for time and accuracy? Thread-Index: AcbTOfCcfRpZq0LwTruTSGi90ME9GwABXrOgAABXLdA= 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: , Errors-To: ecrit-bounces@ietf.org That is what I had in mind. > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, 8 September 2006 10:13 PM > To: 'Andrew Newton'; Thomson, Martin > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Location information in emergency session > initiation,need for time and accuracy? >=20 > I am not an expert here. James may have to correct me, but I believe you > use "best fit", which I believe is max area of overlap. >=20 > With points and polygons, you find the polygon which contains the point. > With polygons (or other area figures like circles) and polygons, you > intersect the location polygons (areas) with each candidate service > boundaries and choose the one that has the largest intersection area. >=20 > Brian >=20 >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 08 09:18:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLgF8-0006I0-Gz; Fri, 08 Sep 2006 09:18:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLgF7-0006HY-Fr for ecrit@ietf.org; Fri, 08 Sep 2006 09:18:01 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLgF6-00079J-8X for ecrit@ietf.org; Fri, 08 Sep 2006 09:18:01 -0400 Received: from [10.0.1.50] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Fri, 08 Sep 2006 09:17:46 -0400 id 0158838C.45016D7A.000073BB In-Reply-To: <02f301c6d340$3410ed10$640fa8c0@cis.neustar.com> References: <02f301c6d340$3410ed10$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Location information in emergency session initiation, need for time and accuracy? Date: Fri, 8 Sep 2006 09:17:48 -0400 To: Brian Rosen X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ecrit@ietf.org, "'Thomson, Martin'" 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: , Errors-To: ecrit-bounces@ietf.org On Sep 8, 2006, at 8:13 AM, Brian Rosen wrote: > I am not an expert here. James may have to correct me, but I > believe you > use "best fit", which I believe is max area of overlap. > > With points and polygons, you find the polygon which contains the > point. > With polygons (or other area figures like circles) and polygons, you > intersect the location polygons (areas) with each candidate service > boundaries and choose the one that has the largest intersection area. I think I understand your point. A point in polygon algorithm is just a type of best-fit. Regardless, I still think that is far more complex than we need out of the gate. Of course, I think it would be short-sighted for us not to have a means to provide for better than points in polygons. That is why I have proposed a means for having profiles and the necessary protocol mechanics to deal with them. Since I have seen no objection to this, I can only assume that nobody minds if we specify it. Regarding best-fit for shapes upon shapes, I'm no expert either. And I expect many of the implementers will be more versed in marshalling XML across the wire and managing connection pools, etc... than in these geometry skills. So, can you provide the algorithms for "best fit" upon which each shape intersects every other shape? I assume you do not mean an indefinite list of shapes but are strictly limiting this to the shapes in Martin's document. Otherwise, I'd like to see an explanation of how the data store and lookup mechanism is to work. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 08 10:37:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLhTm-0003tc-Ku; Fri, 08 Sep 2006 10:37:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLhTl-0003tW-Et for ecrit@ietf.org; Fri, 08 Sep 2006 10:37:13 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLhTi-0000We-5k for ecrit@ietf.org; Fri, 08 Sep 2006 10:37:13 -0400 Received: from lion.cs.columbia.edu (IDENT:kW509EiCceoQ2qXF7r3uJuuDL4a/tkua@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k88EawGb027928 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 8 Sep 2006 10:36:58 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k88Eatg7019869 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 8 Sep 2006 10:36:56 -0400 Message-ID: <45018002.6080305@cs.columbia.edu> Date: Fri, 08 Sep 2006 10:36:50 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] Location information in emergency session initiation, need for time and accuracy? References: <02f301c6d340$3410ed10$640fa8c0@cis.neustar.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=XI, Probability=11%, X-Seen-By filter1.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: ecrit@ietf.org, "'Thomson, Martin'" 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: , Errors-To: ecrit-bounces@ietf.org I think there are three somewhat separable problems: (1) What location information types are permissible in LoST queries and as service areas. (2) How matches are computed within each server. Since it is likely that many LoST implementations will use standard GIS-enabled databases, matches that work with spatial SQL are highly desirable, as implementors may otherwise have to develop either custom databases or sequentially scan a potentially large number of shapes. Anything that requires custom per-server programming is unacceptable. We know that such databases, such as PostGIS, can handle "point-in-polygon" and "boolean intersect", at least for some shapes. So far, it remains unclear whether they support more complicated geometric operations, and at what computational cost. Requiring O(N^2) algorithms is clearly a really bad idea; point-in-polygon is trivially O(N) or O(log N) and can be sped up by indexing. http://www.acm.org/pubs/tog/editors/erich/ptinpoly/ provides some benchmarks on ancient hardware for different algorithms. If you'd want really fast, just run the algorithm on the GPU - it's designed to do this type of stuff hundreds of thousands of times a second... For each shape in (1), we need to at least define how to compute the centroid for that shape, to allow point-in-polygon matches. Assuming that implementors can figure this out for shapes such as arc bands is unrealistic. (3) Most importantly, some non-centroid algorithms would require "forking", i.e., a server for a particular area would have to issue several queries, gather the results and compute the best fit. This forking could be recursive and introduces significant system complexity and failure modes. Henning Andrew Newton wrote: > > On Sep 8, 2006, at 8:13 AM, Brian Rosen wrote: > >> I am not an expert here. James may have to correct me, but I believe you >> use "best fit", which I believe is max area of overlap. >> >> With points and polygons, you find the polygon which contains the point. >> With polygons (or other area figures like circles) and polygons, you >> intersect the location polygons (areas) with each candidate service >> boundaries and choose the one that has the largest intersection area. > > I think I understand your point. A point in polygon algorithm is just a > type of best-fit. Regardless, I still think that is far more complex > than we need out of the gate. Of course, I think it would be > short-sighted for us not to have a means to provide for better than > points in polygons. That is why I have proposed a means for having > profiles and the necessary protocol mechanics to deal with them. Since > I have seen no objection to this, I can only assume that nobody minds if > we specify it. > > Regarding best-fit for shapes upon shapes, I'm no expert either. And I > expect many of the implementers will be more versed in marshalling XML > across the wire and managing connection pools, etc... than in these > geometry skills. So, can you provide the algorithms for "best fit" upon > which each shape intersects every other shape? I assume you do not mean > an indefinite list of shapes but are strictly limiting this to the > shapes in Martin's document. Otherwise, I'd like to see an explanation > of how the data store and lookup mechanism is to work. > > -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 Fri Sep 08 14:11:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLkoK-0008FK-CV; Fri, 08 Sep 2006 14:10:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLkoI-0008DJ-EY; Fri, 08 Sep 2006 14:10:38 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLkoB-0004Lp-TV; Fri, 08 Sep 2006 14:10:38 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 08 Sep 2006 11:10:31 -0700 X-IronPort-AV: i="4.09,134,1157353200"; d="scan'208"; a="319274409:sNHT34407892" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k88IAVk0022754; Fri, 8 Sep 2006 11:10:31 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k88IAN6c006339; Fri, 8 Sep 2006 11:10:30 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 11:10:25 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 11:10:23 -0700 From: "Marc Linsner" To: "'Clive D.W. Feather'" , "'Winterbottom, James'" Subject: RE: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy? Date: Fri, 8 Sep 2006 14:10:19 -0400 Message-ID: <007e01c6d372$0c828290$2b0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <20060908073335.GA9691@finch-staff-1.thus.net> thread-index: AcbTGV3rLC52tGDTSZGKsnPW07RXYgAVTGEA X-OriginalArrivalTime: 08 Sep 2006 18:10:24.0738 (UTC) FILETIME=[0E5D8420:01C6D372] DKIM-Signature: a=rsa-sha1; q=dns; l=3552; t=1157739031; x=1158603031; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=22Marc=20Linsner=22=20 |Subject:RE=3A=20[Ecrit]=20Location=20information=20in=20emergency=20sessioniniti ation,need=20for=20time=20and=20accuracy?; X=v=3Dcisco.com=3B=20h=3DDeBnvD7aPVFo3uIn1zbxAYE9EaQ=3D; b=qs//86FFtvVgfGfHKgjwB6vkhlc54llddUcaEdLgvwhnASD4IjNnPFOagRuULCtoCxbDP1OO FMI7zPKFCxJ+BQE79NfPdZhPSOH+FU8XrGqwgfKZPMBnWYK55ZCzZdqx; Authentication-Results: sj-dkim-8.cisco.com; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: geopriv@ietf.org, 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: , Errors-To: ecrit-bounces@ietf.org Could someone please identify any/all application(s) where geo coordinates are used to describe the location of a fixed (e.g. non-mobile) entity where uncertainty/polygons are expressed? I've reviewed many aviation/marine charts/data (very pervasive use of geo coordinates) that express geo locations for fixed objects and I've yet to find any expressed with uncertainty. (I'm 70% confident you'll find a runway at x,y,z) RFC3825: - is NOT intended to advise a mobile client of it's location (as suggested in the text, it could possibly convey the location of the access point) - is NOT a mechanism for expressing polygons - is capable of conveying a 3 dimensional geo point from one entity to another via dhcp - is capable of expressing the resolution of the shown value - is capable of allowing the creator of the object to express resolution values other than what is actually known - is an efficient mechanism for passing geo point location values via dhcp ...............snip.................... > > 3825 does not explain in normative text: > - that the encoding is twos complement (sign and magnitude would > probably > be more sensible in this context); As seen in the quote below, it certainly specifies twos complement. In the 1960s problems with this representation were identified and resolved with twos complement representation. http://en.wikipedia.org/wiki/Signed_number_representations "Within the LCI described here, Latitude and Longitude are represented in fixed-point 2s-complement binary degrees, for the economy of a smaller option size compared to a string encoding of digits in [7]. The integer parts of these fields are 9 bits long to accommodate +/- 180 degrees. The fractional part is 25 bits long, better than the precision of 7 decimal digits. The length of each field is 40 bits, 34 of which is the sum of the integer (9) and fractional (25) bits, plus 6 bits of resolution." > - how to construct a rectangle that crosses the Prime Meridian or the > equator; RFC 3825 is not about representing arbitrary rectangles, but about representing a geographic location, with explicit indication of the resolution of the point. > - what is the meaning of a value that is, or includes cases, outside > the > +/-90 or +/-180 range (the SHOULD be in range rule doesn't cut it, > here). One could extrapolate many meanings from values expressed that are outside the SHOULD of the RFC. One of those meanings may be that the value expressed is an error. Or a value outside the specified range could be an alias (wrapping the globe) for a value within the specified ranges. The "SHOULD" allows those who understand the complications to violate this specification, but warns of unintended consequences. > > It's also a bad encoding because it requires boundaries to be aligned > to units of the same size as the boundary. For example, if I want to > define an area 2 degrees high, I have to use boundaries that are even > numbers of degrees; there's no way to encode a square, 2 degrees on a > side, centred on 52N 2W. > > In fact, the *only* encoding I can do for an area centred on that > point is a rectangle 4 degrees east-west and 8 degrees north-south. > For *any* point, there's only one rectangle with that point at its > centre that can be encoded. Since there is no arbitrary rectangle specified in RFC 3825, it does not require anything about boundaries of any rectangle. ..................snip............................ -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 08 17:47:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLoBu-0003oz-Fw; Fri, 08 Sep 2006 17:47:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLoBt-0003or-3X; Fri, 08 Sep 2006 17:47:13 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLoBr-0005wG-4O; Fri, 08 Sep 2006 17:47:13 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 16:47:10 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Fri, 08 Sep 2006 16:47:10 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 16:47:09 -0500 Message-ID: From: "Winterbottom, James" To: "Marc Linsner" , "Clive D.W. Feather" Date: Fri, 8 Sep 2006 16:47:05 -0500 Subject: RE: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 08 Sep 2006 21:47:09.0473 (UTC) FILETIME=[55CA9910:01C6D390] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <007e01c6d372$0c828290$2b0d0d0a@amer.cisco.com> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy? Thread-Index: AcbTGV3rLC52tGDTSZGKsnPW07RXYgAVTGEAAAfyCUA= X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: geopriv@ietf.org, 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: , Errors-To: ecrit-bounces@ietf.org Marc, I would like you and James to get your arguments in synch and come back with a cohesive, uncontradictory response to the concerns that are being raised here. You say " is NOT a mechanism for expressing polygons" and have said before that you see it as a mechanisms for expressing single points only. James said " RFC3825 has resolution as part of its solution. This creates a GML defined Linear Ring.." These are in direct conflict. The moment you use the resolution bits to describe a linear ring, you are specifying a polygon, which by its very definition defines the area of uncertainty for the host. The coding mechanism described in RFC-3825 for doing this introduces the problems that we have described. So, either it is a point, in which case the resolution for the most part should be ignored and a Biz to RFC-3825 is required to say this. Or, it is an area which is described by the resolution bits, in which case you need to find a way to eliminate the problems described or accept that it should not be used in emergency applications. I am only interested in location representation, and so far I see conflict amongst the authors of that RFC with regards to what RFC-3825 represents and I see confusion over how the authors are interpreting the terms uncertainty and confidence with regards to their usage in the expression to areas. Cheers James > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Saturday, 9 September 2006 4:10 AM > To: 'Clive D.W. Feather'; Winterbottom, James > Cc: ecrit@ietf.org; geopriv@ietf.org > Subject: RE: [Ecrit] Location information in emergency > sessioninitiation,need for time and accuracy? >=20 > Could someone please identify any/all application(s) where geo coordinates > are used to describe the location of a fixed (e.g. non-mobile) entity > where > uncertainty/polygons are expressed? I've reviewed many aviation/marine > charts/data (very pervasive use of geo coordinates) that express geo > locations for fixed objects and I've yet to find any expressed with > uncertainty. (I'm 70% confident you'll find a runway at x,y,z) >=20 > RFC3825: >=20 > - is NOT intended to advise a mobile client of it's location (as suggested > in the text, it could possibly convey the location of the access point) > - is NOT a mechanism for expressing polygons > - is capable of conveying a 3 dimensional geo point from one entity to > another via dhcp > - is capable of expressing the resolution of the shown value > - is capable of allowing the creator of the object to express resolution > values other than what is actually known > - is an efficient mechanism for passing geo point location values via dhcp >=20 >=20 > ...............snip.................... >=20 >=20 > > > > 3825 does not explain in normative text: > > - that the encoding is twos complement (sign and magnitude would > > probably > > be more sensible in this context); >=20 > As seen in the quote below, it certainly specifies twos complement. In > the > 1960s problems with this representation were identified and resolved with > twos complement representation. > http://en.wikipedia.org/wiki/Signed_number_representations >=20 > "Within the LCI described here, Latitude and Longitude are represented in > fixed-point 2s-complement binary degrees, for the economy of a smaller > option size compared to a string encoding of digits in [7]. The integer > parts of these fields are 9 bits long to accommodate +/- 180 degrees. The > fractional part is 25 bits long, better than the precision of 7 decimal > digits. The length of each field is 40 bits, 34 of which is the sum of > the > integer (9) and fractional (25) bits, plus 6 bits of resolution." >=20 >=20 > > - how to construct a rectangle that crosses the Prime Meridian or the > > equator; >=20 > RFC 3825 is not about representing arbitrary rectangles, but about > representing a geographic location, with explicit indication of the > resolution of the point. >=20 > > - what is the meaning of a value that is, or includes cases, outside > > the > > +/-90 or +/-180 range (the SHOULD be in range rule doesn't cut it, > > here). >=20 > One could extrapolate many meanings from values expressed that are outside > the SHOULD of the RFC. One of those meanings may be that the value > expressed is an error. Or a value outside the specified range could be an > alias (wrapping the globe) for a value within the specified ranges. The > "SHOULD" allows those who understand the complications to violate this > specification, but warns of unintended consequences. >=20 >=20 > > > > It's also a bad encoding because it requires boundaries to be aligned > > to units of the same size as the boundary. For example, if I want to > > define an area 2 degrees high, I have to use boundaries that are even > > numbers of degrees; there's no way to encode a square, 2 degrees on a > > side, centred on 52N 2W. > > > > In fact, the *only* encoding I can do for an area centred on that > > point is a rectangle 4 degrees east-west and 8 degrees north-south. > > For *any* point, there's only one rectangle with that point at its > > centre that can be encoded. >=20 > Since there is no arbitrary rectangle specified in RFC 3825, it does not > require anything about boundaries of any rectangle. >=20 > ..................snip............................ >=20 > -Marc- ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 08 18:02:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLoQg-00028x-RN; Fri, 08 Sep 2006 18:02:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLoQf-00028p-BX; Fri, 08 Sep 2006 18:02:29 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLoQe-0007AW-2L; Fri, 08 Sep 2006 18:02:29 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 08 Sep 2006 15:02:27 -0700 X-IronPort-AV: i="4.09,134,1157353200"; d="scan'208"; a="340516764:sNHT28779624" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k88M2RSa025190; Fri, 8 Sep 2006 15:02:27 -0700 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 k88M2RYp005274; Fri, 8 Sep 2006 15:02:27 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 15:02:26 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 15:02:25 -0700 From: "Marc Linsner" To: "'Winterbottom, James'" Subject: RE: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy? Date: Fri, 8 Sep 2006 18:02:16 -0400 Message-ID: <000601c6d392$7633ccb0$2b0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbTGV3rLC52tGDTSZGKsnPW07RXYgAVTGEAAAfyCUAAAOacsA== In-Reply-To: X-OriginalArrivalTime: 08 Sep 2006 22:02:26.0244 (UTC) FILETIME=[783AC040:01C6D392] DKIM-Signature: a=rsa-sha1; q=dns; l=532; t=1157752947; x=1158616947; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=22Marc=20Linsner=22=20 |Subject:RE=3A=20[Ecrit]=20Location=20information=20in=20emergency=20sessioniniti ation,need=20for=20time=20and=20accuracy?; X=v=3Dcisco.com=3B=20h=3DDeBnvD7aPVFo3uIn1zbxAYE9EaQ=3D; b=sKMeUlYj16R6Gjiz0QxY3lIXH6II0KJ5oYYqddyUouRlutaF2egFgnE1k1te/DAeTWYJ037z LAtuoB1cRgN0ZPL9WFwtnmDzZdzDSwrCw2t3+6Wnyp0BOg1Wg7DtF+KA; Authentication-Results: sj-dkim-2.cisco.com; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: geopriv@ietf.org, 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: , Errors-To: ecrit-bounces@ietf.org James, > > So, either it is a point, in which case the resolution for > the most part should be ignored and a Biz to RFC-3825 is > required to say this. Or, it is an area which is described by > the resolution bits, in which case you need to find a way to > eliminate the problems described or accept that it should not > be used in emergency applications. Please explain why emergency applications are different from other applications that describe fixed locations using the geo coordinate system. -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 08 18:11:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLoZ3-0002g4-Us; Fri, 08 Sep 2006 18:11:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLoZ3-0002fv-LO; Fri, 08 Sep 2006 18:11:09 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLoZ1-0008Jg-Dh; Fri, 08 Sep 2006 18:11:09 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 17:11:07 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Fri, 08 Sep 2006 17:11:06 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 17:11:06 -0500 Message-ID: From: "Winterbottom, James" To: "Marc Linsner" Date: Fri, 8 Sep 2006 17:11:05 -0500 Subject: RE: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 08 Sep 2006 22:11:06.0569 (UTC) FILETIME=[AE5E0B90:01C6D393] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <000601c6d392$7633ccb0$2b0d0d0a@amer.cisco.com> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy? Thread-Index: AcbTGV3rLC52tGDTSZGKsnPW07RXYgAVTGEAAAfyCUAAAOacsAAAYhNQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: geopriv@ietf.org, 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: , Errors-To: ecrit-bounces@ietf.org Marc, Perhaps the statement should have been, is not suitable for any application that require a deterministic degree of accuracy, something to that effect. I am quite sure that in some circumstances that the encoding scheme is fine, but I wouldn't want to be my life on it in an emergency, would you? James > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Saturday, 9 September 2006 8:02 AM > To: Winterbottom, James > Cc: ecrit@ietf.org; geopriv@ietf.org > Subject: RE: [Ecrit] Location information in emergency > sessioninitiation,need for time and accuracy? >=20 > James, >=20 > > > > So, either it is a point, in which case the resolution for > > the most part should be ignored and a Biz to RFC-3825 is > > required to say this. Or, it is an area which is described by > > the resolution bits, in which case you need to find a way to > > eliminate the problems described or accept that it should not > > be used in emergency applications. >=20 > Please explain why emergency applications are different from other > applications that describe fixed locations using the geo coordinate > system. >=20 >=20 > -Marc- ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 08 18:30:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLorO-000111-5O; Fri, 08 Sep 2006 18:30:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLorN-00010s-9g; Fri, 08 Sep 2006 18:30:05 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLorK-0002RX-Ti; Fri, 08 Sep 2006 18:30:05 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 08 Sep 2006 15:29:21 -0700 X-IronPort-AV: i="4.09,134,1157353200"; d="scan'208"; a="340520031:sNHT2409188040" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k88MTK5u014615; Fri, 8 Sep 2006 15:29:20 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k88MTJYp019709; Fri, 8 Sep 2006 15:29:19 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Sep 2006 15:29:19 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 15:29:19 -0700 From: "Marc Linsner" To: "'Winterbottom, James'" Subject: RE: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy? Date: Fri, 8 Sep 2006 18:29:12 -0400 Message-ID: <000b01c6d396$37c8a7d0$2b0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbTGV3rLC52tGDTSZGKsnPW07RXYgAVTGEAAAfyCUAAAOacsAAAYhNQAAAstRA= In-Reply-To: X-OriginalArrivalTime: 08 Sep 2006 22:29:19.0287 (UTC) FILETIME=[39AD9470:01C6D396] DKIM-Signature: a=rsa-sha1; q=dns; l=658; t=1157754560; x=1158618560; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=22Marc=20Linsner=22=20 |Subject:RE=3A=20[Ecrit]=20Location=20information=20in=20emergency=20sessioniniti ation,need=20for=20time=20and=20accuracy?; X=v=3Dcisco.com=3B=20h=3DDeBnvD7aPVFo3uIn1zbxAYE9EaQ=3D; b=Suqsgj4ISgSNU6a9SeLWCPomXxrrGpZ3+oGtnV4trobdUwczdhWTfZlJ3FOLuiVNHuFpKeyx 2UkmUerdCBU2v0SVq6jECU3FfVKlX+w+22w0y+vZB9qn+wyE0fxoV3Gx; Authentication-Results: sj-dkim-2.cisco.com; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: geopriv@ietf.org, 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: , Errors-To: ecrit-bounces@ietf.org > > Marc, > > Perhaps the statement should have been, is not suitable for > any application that require a deterministic degree of > accuracy, something to that effect. > I am quite sure that in some circumstances that the encoding > scheme is fine, but I wouldn't want to be my life on it in an > emergency, would you? I suggest emergency responders would have no problem finding locations described by RFC3825, it's the same data expressions used by aviation and marine everyday. So, unless you travel exclusively by rail, you've probably already placed you life in the hands of such data representation, I know I have. -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 08 18:36:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLoxP-0001xf-5T; Fri, 08 Sep 2006 18:36:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLoxN-0001xU-TN for ecrit@ietf.org; Fri, 08 Sep 2006 18:36:17 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLoxM-0003YS-6z for ecrit@ietf.org; Fri, 08 Sep 2006 18:36:17 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 08 Sep 2006 15:36:15 -0700 X-IronPort-AV: i="4.09,135,1157353200"; d="scan'208"; a="319356980:sNHT31348416" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k88MaFA4000642; Fri, 8 Sep 2006 15:36:15 -0700 Received: from [68.50.22.220] (che-vpn-cluster-2-128.cisco.com [10.86.242.128]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k88MaEuI014972; Fri, 8 Sep 2006 18:36:14 -0400 (EDT) In-Reply-To: <6C65226A-5DD4-42F0-BE43-8D4355BBB098@hxr.us> References: <018501c6d2ac$a4807e10$640fa8c0@cis.neustar.com> <450099DA.4060600@cs.columbia.edu> <6C65226A-5DD4-42F0-BE43-8D4355BBB098@hxr.us> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: [Ecrit] Location information in emergency session initiation, need for time and accuracy? Date: Fri, 8 Sep 2006 18:36:10 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.624) DKIM-Signature: a=rsa-sha1; q=dns; l=1372; t=1157754975; x=1158618975; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jschnizl@cisco.com; z=From:John=20Schnizlein=20 |Subject:Re=3A=20[Ecrit]=20Location=20information=20in=20emergency=20session=09in itiation,=20need=20for=20time=20and=20accuracy?; X=v=3Dcisco.com=3B=20h=3D/E5rlIqeSPNPlMu6j1UHzb0KgV8=3D; b=B+xIX6A/RHKvOVhpN+NHoKrYSXWlQO0nBLmLKBtupjIPxAIHbSF3dzNzXiHmmmptwsN7dFkt OmIOBVzPmRZr9UBGpBzemzFFmQezKqiK9v15lNiqir+5TIyvZI/0KPXV; Authentication-Results: sj-dkim-7.cisco.com; header.From=jschnizl@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Are you saying that the 5 embassies would each actually have their own PSAPs? Or is this "use case" in the "fanciful" category? But Brian's point was really about separate floors rather than autonomous regions in close lateral proximity. Is there a non-fanciful real-world use case that implies that the routing of an emergency call should depend on the floor where the call originates? As a case that might combine these fancies, it happens that the Swedish Embassy leases suites on other floors of its building on M Street. Do you know that emergency calls from these floors are routed differently than emergency calls from the floors the Swedish diplomats occupy? John On Sep 7, 2006, at 9:06 PM, Andrew Newton wrote: > > On Sep 7, 2006, at 6:14 PM, Henning Schulzrinne wrote: >> >> Brian Rosen wrote: >>> I thought I heard you giving use cases. As I recall, it was >>> something like >>> a university with a local EMS responder occupying some number of >>> floors of a >>> building. >> >> If I said it, consider it in the "fanciful" category :-) > > I've got one... > A well placed WiFi AP in Washington, D.C.'s Dupont Circle could > probably have a service area of 5 separate countries... given that > each embassy is sovereign soil. A cell tower or WiMAX AP could > probably service 40 or 50 separate countries. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 08 18:52:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLpD8-0000h3-BX; Fri, 08 Sep 2006 18:52:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLpD6-0000dC-UQ; Fri, 08 Sep 2006 18:52:32 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLpD5-0000Ds-Mc; Fri, 08 Sep 2006 18:52:32 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 17:52:31 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Fri, 08 Sep 2006 17:52:30 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 17:52:30 -0500 Message-ID: From: "Winterbottom, James" To: "Marc Linsner" Date: Fri, 8 Sep 2006 17:52:30 -0500 Subject: RE: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 08 Sep 2006 22:52:30.0289 (UTC) FILETIME=[76C7A410:01C6D399] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <000b01c6d396$37c8a7d0$2b0d0d0a@amer.cisco.com> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy? Thread-Index: AcbTGV3rLC52tGDTSZGKsnPW07RXYgAVTGEAAAfyCUAAAOacsAAAYhNQAAAstRAAALMNEA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: geopriv@ietf.org, 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: , Errors-To: ecrit-bounces@ietf.org It is interesting that you point this out and I am certainly no expert in aviation and marine location systems. I will however point out that from what I have seen that searches at sea and for downed aircraft often span many thousands of square kilometres, I scarcely think that this would be acceptable in a domestic wired or wireless phone emergency situation. I would also point out that if you have used the same encoding as is used in those industries it behoves you to have put them in the references section of the RFC, and to have indicated that the encoding scheme came from the there in the text somewhere, I certainly couldn't find any. Now back to my initial series of questions: Point or Polygon, single answer please. How do you intend to address the concern regarding errors. Cheers James > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Saturday, 9 September 2006 8:29 AM > To: Winterbottom, James > Cc: ecrit@ietf.org; geopriv@ietf.org > Subject: RE: [Ecrit] Location information in emergency > sessioninitiation,need for time and accuracy? >=20 >=20 > > > > Marc, > > > > Perhaps the statement should have been, is not suitable for > > any application that require a deterministic degree of > > accuracy, something to that effect. > > I am quite sure that in some circumstances that the encoding > > scheme is fine, but I wouldn't want to be my life on it in an > > emergency, would you? >=20 > I suggest emergency responders would have no problem finding locations > described by RFC3825, it's the same data expressions used by aviation and > marine everyday. So, unless you travel exclusively by rail, you've > probably > already placed you life in the hands of such data representation, I know I > have. >=20 > -Marc- ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 08 19:15:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLpZH-0003x3-Ut; Fri, 08 Sep 2006 19:15:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLpZG-0003wy-U7 for ecrit@ietf.org; Fri, 08 Sep 2006 19:15:26 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLpZF-0006wT-O4 for ecrit@ietf.org; Fri, 08 Sep 2006 19:15:26 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 18:15:25 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Fri, 08 Sep 2006 18:15:25 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 18:15:24 -0500 Message-ID: From: "Thomson, Martin" To: "Andrew Newton" Date: Fri, 8 Sep 2006 18:14:00 -0500 Subject: RE: [Ecrit] Location information in emergency session initiation, need for time and accuracy? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 08 Sep 2006 23:15:24.0887 (UTC) FILETIME=[AA1AA670:01C6D39C] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 References: <22A9A973-7DDA-491F-8359-EBD83438B9D0@hxr.us> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Location information in emergency session initiation, need for time and accuracy? Thread-Index: AcbTOc2P/+p3rJ7DQLCQ14qjQ5hkIwAYqqER X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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: , Errors-To: ecrit-bounces@ietf.org > Ok. How do I know which server to ask? I think that you missed my point; I am talking about any individual server = in the entire system. Martin ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 08 19:27:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLpkg-0004KW-8x; Fri, 08 Sep 2006 19:27:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLpkf-0004KL-6H for ecrit@ietf.org; Fri, 08 Sep 2006 19:27:13 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLpkd-000078-QY for ecrit@ietf.org; Fri, 08 Sep 2006 19:27:13 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 18:27:11 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Fri, 08 Sep 2006 18:27:10 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 18:27:10 -0500 Message-ID: From: "Thomson, Martin" To: "Henning Schulzrinne" , "Andrew Newton" Date: Fri, 8 Sep 2006 18:27:09 -0500 Subject: RE: [Ecrit] Location information in emergency session initiation, need for time and accuracy? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 08 Sep 2006 23:27:10.0480 (UTC) FILETIME=[4EAB9900:01C6D39E] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 References: <02f301c6d340$3410ed10$640fa8c0@cis.neustar.com> <45018002.6080305@cs.columbia.edu> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Location information in emergency session initiation, need for time and accuracy? Thread-Index: AcbTVEAillV62lr7QjKQt/bqbGCWJQASNTMV X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 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: , Errors-To: ecrit-bounces@ietf.org Can you see any problem with specifying a fast and efficient method for cal= culating a centroid, but also permitting the use of more sophisticated meth= ods? I say this because every time the performance argument is raised, up = goes a little red flag. (Yes, yes, it isn't all about performance). For 1: I would say that the limited set of shapes in geo-shape should be pe= rmitted. For 3: I can see that forking would be a bad idea for a number of reasons, = I don't think that it should be encouraged. -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Sat 9/9/2006 12:36 AM To: Andrew Newton Cc: Brian Rosen; ecrit@ietf.org; Thomson, Martin Subject: Re: [Ecrit] Location information in emergency session initiation, = need for time and accuracy? =20 I think there are three somewhat separable problems: (1) What location information types are permissible in LoST queries and=20 as service areas. (2) How matches are computed within each server. Since it is likely that many LoST implementations will use standard GIS-enabled databases,=20 matches that work with spatial SQL are highly desirable, as implementors may otherwise have to develop either custom databases or sequentially=20 scan a potentially large number of shapes. Anything that requires custom per-server programming is unacceptable. We know that such databases, such as PostGIS, can handle=20 "point-in-polygon" and "boolean intersect", at least for some shapes. So far, it remains unclear whether they support more complicated geometric=20 operations, and at what computational cost. Requiring O(N^2) algorithms=20 is clearly a really bad idea; point-in-polygon is trivially O(N) or=20 O(log N) and can be sped up by indexing. http://www.acm.org/pubs/tog/editors/erich/ptinpoly/ provides some=20 benchmarks on ancient hardware for different algorithms. If you'd want=20 really fast, just run the algorithm on the GPU - it's designed to do=20 this type of stuff hundreds of thousands of times a second... For each shape in (1), we need to at least define how to compute the=20 centroid for that shape, to allow point-in-polygon matches. Assuming=20 that implementors can figure this out for shapes such as arc bands is=20 unrealistic. (3) Most importantly, some non-centroid algorithms would require=20 "forking", i.e., a server for a particular area would have to issue=20 several queries, gather the results and compute the best fit. This=20 forking could be recursive and introduces significant system complexity=20 and failure modes. Henning Andrew Newton wrote: >=20 > On Sep 8, 2006, at 8:13 AM, Brian Rosen wrote: >=20 >> I am not an expert here. James may have to correct me, but I believe yo= u >> use "best fit", which I believe is max area of overlap. >> >> With points and polygons, you find the polygon which contains the point. >> With polygons (or other area figures like circles) and polygons, you >> intersect the location polygons (areas) with each candidate service >> boundaries and choose the one that has the largest intersection area. >=20 > I think I understand your point. A point in polygon algorithm is just a > type of best-fit. Regardless, I still think that is far more complex=20 > than we need out of the gate. Of course, I think it would be=20 > short-sighted for us not to have a means to provide for better than=20 > points in polygons. That is why I have proposed a means for having=20 > profiles and the necessary protocol mechanics to deal with them. Since > I have seen no objection to this, I can only assume that nobody minds if > we specify it. >=20 > Regarding best-fit for shapes upon shapes, I'm no expert either. And I > expect many of the implementers will be more versed in marshalling XML > across the wire and managing connection pools, etc... than in these=20 > geometry skills. So, can you provide the algorithms for "best fit" upon > which each shape intersects every other shape? I assume you do not mean > an indefinite list of shapes but are strictly limiting this to the=20 > shapes in Martin's document. Otherwise, I'd like to see an explanation > of how the data store and lookup mechanism is to work. >=20 > -andy >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 08 19:42:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLpz8-0000Sl-Gp; Fri, 08 Sep 2006 19:42:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLpz7-0000Ql-RX; Fri, 08 Sep 2006 19:42:09 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLpz6-0001Gg-An; Fri, 08 Sep 2006 19:42:09 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-6.cisco.com with ESMTP; 08 Sep 2006 16:42:07 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k88Ng73m020696; Fri, 8 Sep 2006 16:42:07 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k88Ng76W002782; Fri, 8 Sep 2006 16:42:07 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 16:42:06 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 16:42:02 -0700 From: "Marc Linsner" To: "'Winterbottom, James'" Subject: RE: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy? Date: Fri, 8 Sep 2006 19:41:55 -0400 Message-ID: <001001c6d3a0$625b0c40$2b0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbTGV3rLC52tGDTSZGKsnPW07RXYgAVTGEAAAfyCUAAAOacsAAAYhNQAAAstRAAALMNEAABCiww In-Reply-To: X-OriginalArrivalTime: 08 Sep 2006 23:42:05.0968 (UTC) FILETIME=[646C3900:01C6D3A0] DKIM-Signature: a=rsa-sha1; q=dns; l=3905; t=1157758927; x=1158622927; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=22Marc=20Linsner=22=20 |Subject:RE=3A=20[Ecrit]=20Location=20information=20in=20emergency=20sessioniniti ation,need=20for=20time=20and=20accuracy?; X=v=3Dcisco.com=3B=20h=3DDeBnvD7aPVFo3uIn1zbxAYE9EaQ=3D; b=xyItbd8aefrFOsrOqg1Izpwgkq3TdLXWmGuhs1pbSp8aWbiqWcHBJCBKcZbmRwUsn9FxvByj K46UHOkfrR+H0HsXb9rf82A2a9/QKFIvUq4rxlIyYXrfOYiCnXQQ7OzB; Authentication-Results: sj-dkim-5.cisco.com; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: geopriv@ietf.org, 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: , Errors-To: ecrit-bounces@ietf.org James, We are obviously talking past each other. I used the aviation and marine industries as examples of users of geo coordinates for their respective navigation applications. I used that analogy because both those applications commonly refer to fixed locations (e.g. airport runways, marine buoys/markers), the same non-mobile type entities served by RFC3825 (the commonality being 'non-mobile, not the application). I can't testify whether these application implementations internally represent data in binary, octal, decimal, etc. But I can attest that these applications DO NOT express any kind of uncertainty association in addition to the location representations. My experience with these applications have been with variable length fields, hence a separate resolution parameter has not been included. Resolution, whether expressed in binary, octal, decimal, etc. cannot represent an arbitrary area/shape. Hence, RFC3825 cannot express an arbitrary area/shape as it only includes resolution. Would you please expand your question concerning errors? What errors? -Marc- > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Friday, September 08, 2006 6:53 PM > To: Marc Linsner > Cc: ecrit@ietf.org; geopriv@ietf.org > Subject: RE: [Ecrit] Location information in emergency > sessioninitiation,need for time and accuracy? > > It is interesting that you point this out and I am certainly > no expert in aviation and marine location systems. I will > however point out that from what I have seen that searches at > sea and for downed aircraft often span many thousands of > square kilometres, I scarcely think that this would be > acceptable in a domestic wired or wireless phone emergency situation. > > I would also point out that if you have used the same > encoding as is used in those industries it behoves you to > have put them in the references section of the RFC, and to > have indicated that the encoding scheme came from the there > in the text somewhere, I certainly couldn't find any. > > Now back to my initial series of questions: > > Point or Polygon, single answer please. > How do you intend to address the concern regarding errors. > > Cheers > James > > > > -----Original Message----- > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > Sent: Saturday, 9 September 2006 8:29 AM > > To: Winterbottom, James > > Cc: ecrit@ietf.org; geopriv@ietf.org > > Subject: RE: [Ecrit] Location information in emergency > > sessioninitiation,need for time and accuracy? > > > > > > > > > > Marc, > > > > > > Perhaps the statement should have been, is not suitable for any > > > application that require a deterministic degree of accuracy, > > > something to that effect. > > > I am quite sure that in some circumstances that the > encoding scheme > > > is fine, but I wouldn't want to be my life on it in an emergency, > > > would you? > > > > I suggest emergency responders would have no problem > finding locations > > described by RFC3825, it's the same data expressions used > by aviation > and > > marine everyday. So, unless you travel exclusively by rail, you've > > probably already placed you life in the hands of such data > > representation, I > know I > > have. > > > > -Marc- > > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 08 19:53:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLqA1-00018c-JE; Fri, 08 Sep 2006 19:53:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLqA0-00018X-H5 for ecrit@ietf.org; Fri, 08 Sep 2006 19:53:24 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLq9z-0003Os-Aj for ecrit@ietf.org; Fri, 08 Sep 2006 19:53:24 -0400 Received: from [10.0.1.50] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Fri, 08 Sep 2006 19:53:01 -0400 id 01588176.4502025D.00006518 In-Reply-To: References: <018501c6d2ac$a4807e10$640fa8c0@cis.neustar.com> <450099DA.4060600@cs.columbia.edu> <6C65226A-5DD4-42F0-BE43-8D4355BBB098@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3C82667E-35EB-4281-90E4-782F9D10EF90@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Location information in emergency session initiation, need for time and accuracy? Date: Fri, 8 Sep 2006 19:53:05 -0400 To: John Schnizlein X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) 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: , Errors-To: ecrit-bounces@ietf.org I was one for the "fanciful" category. -andy On Sep 8, 2006, at 6:36 PM, John Schnizlein wrote: > Are you saying that the 5 embassies would each actually have their > own PSAPs? Or is this "use case" in the "fanciful" category? > > But Brian's point was really about separate floors rather than > autonomous regions in close lateral proximity. Is there a non- > fanciful real-world use case that implies that the routing of an > emergency call should depend on the floor where the call originates? > > As a case that might combine these fancies, it happens that the > Swedish Embassy leases suites on other floors of its building on M > Street. Do you know that emergency calls from these floors are > routed differently than emergency calls from the floors the Swedish > diplomats occupy? > > John > > On Sep 7, 2006, at 9:06 PM, Andrew Newton wrote: >> >> On Sep 7, 2006, at 6:14 PM, Henning Schulzrinne wrote: >>> >>> Brian Rosen wrote: >>>> I thought I heard you giving use cases. As I recall, it was >>>> something like >>>> a university with a local EMS responder occupying some number of >>>> floors of a >>>> building. >>> >>> If I said it, consider it in the "fanciful" category :-) >> >> I've got one... >> A well placed WiFi AP in Washington, D.C.'s Dupont Circle could >> probably have a service area of 5 separate countries... given that >> each embassy is sovereign soil. A cell tower or WiMAX AP could >> probably service 40 or 50 separate countries. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 08 20:08:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLqOP-0002UE-KW; Fri, 08 Sep 2006 20:08:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLqOO-0002U9-Bq for ecrit@ietf.org; Fri, 08 Sep 2006 20:08:16 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLqOL-0005y8-VO for ecrit@ietf.org; Fri, 08 Sep 2006 20:08:16 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 08 Sep 2006 17:08:13 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8908Dk6003416; Fri, 8 Sep 2006 17:08:13 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8908DQV002080; Fri, 8 Sep 2006 17:08:13 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 17:08:13 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 17:08:12 -0700 From: "Marc Linsner" To: "'Andrew Newton'" , "'John Schnizlein'" Subject: RE: [Ecrit] Location information in emergency session initiation, need for time and accuracy? Date: Fri, 8 Sep 2006 20:08:04 -0400 Message-ID: <001401c6d3a4$081e2b50$2b0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbTol+tZBaxxdK4Rc+4K0SrtjGiMAAAC8tA In-Reply-To: <3C82667E-35EB-4281-90E4-782F9D10EF90@hxr.us> X-OriginalArrivalTime: 09 Sep 2006 00:08:12.0629 (UTC) FILETIME=[0A39B850:01C6D3A4] DKIM-Signature: a=rsa-sha1; q=dns; l=2554; t=1157760493; x=1158624493; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=22Marc=20Linsner=22=20 |Subject:RE=3A=20[Ecrit]=20Location=20information=20in=20emergency=20session=09in itiation,need=20for=20time=20and=20accuracy?; X=v=3Dcisco.com=3B=20h=3DT7BMoArdy+dEUGPTq+Ck2XYL0+A=3D; b=Lk/HYPctuA6nkbsN3rp9mJYoavxx/+UE+65UU9cWTnc4sqbI6krJ7YxrG2g7S40XMKMmGZJZ eZW76nUwCj4x5wp4ViazPfY0Wpv2YUiuBF1VVj+2QKH2HT5rwIfL5fkA; Authentication-Results: sj-dkim-1.cisco.com; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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: , Errors-To: ecrit-bounces@ietf.org fwiw.....NENA submitted a requirement for routing on the 'z' dimension. The use case was the top 55 floors of the Sears tower could get routed to a different PSAP than the bottom 55 floors, reasonable since there are over 10,000 occupants of that building at certain times. This requirement is not 'fanciful' as it is achieveble with the current PSTN 911 architecture. I suggest we accomodate such in the 'newer, better' IP system, regression of features doesn't bode well in marketing the Internet. -Marc- > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Friday, September 08, 2006 7:53 PM > To: John Schnizlein > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Location information in emergency > session initiation,need for time and accuracy? > > I was one for the "fanciful" category. > > -andy > > On Sep 8, 2006, at 6:36 PM, John Schnizlein wrote: > > > Are you saying that the 5 embassies would each actually > have their own > > PSAPs? Or is this "use case" in the "fanciful" category? > > > > But Brian's point was really about separate floors rather than > > autonomous regions in close lateral proximity. Is there a non- > > fanciful real-world use case that implies that the routing of an > > emergency call should depend on the floor where the call originates? > > > > As a case that might combine these fancies, it happens that the > > Swedish Embassy leases suites on other floors of its building on M > > Street. Do you know that emergency calls from these floors > are routed > > differently than emergency calls from the floors the > Swedish diplomats > > occupy? > > > > John > > > > On Sep 7, 2006, at 9:06 PM, Andrew Newton wrote: > >> > >> On Sep 7, 2006, at 6:14 PM, Henning Schulzrinne wrote: > >>> > >>> Brian Rosen wrote: > >>>> I thought I heard you giving use cases. As I recall, it was > >>>> something like a university with a local EMS responder occupying > >>>> some number of floors of a building. > >>> > >>> If I said it, consider it in the "fanciful" category :-) > >> > >> I've got one... > >> A well placed WiFi AP in Washington, D.C.'s Dupont Circle could > >> probably have a service area of 5 separate countries... given that > >> each embassy is sovereign soil. A cell tower or WiMAX AP could > >> probably service 40 or 50 separate countries. > > > _______________________________________________ > 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 Sep 08 20:25:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLqeU-000630-VZ; Fri, 08 Sep 2006 20:24:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLqeT-00062v-Lf for ecrit@ietf.org; Fri, 08 Sep 2006 20:24:53 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLqeP-0000Yw-DL for ecrit@ietf.org; Fri, 08 Sep 2006 20:24:53 -0400 Received: from [192.168.0.41] (pool-141-153-175-20.mad.east.verizon.net [141.153.175.20]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k890OgGl011906 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 8 Sep 2006 20:24:43 -0400 (EDT) In-Reply-To: References: <02f301c6d340$3410ed10$640fa8c0@cis.neustar.com> <45018002.6080305@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <68A34B91-DFBC-434F-9A30-8B53A716BDFA@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Location information in emergency session initiation, need for time and accuracy? Date: Fri, 8 Sep 2006 20:24:35 -0400 To: "Thomson, Martin" X-Mailer: Apple Mail (2.752.2) X-PerlMx-Spam: Gauge=XXII, Probability=22%, X-Seen-By filter1.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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: , Errors-To: ecrit-bounces@ietf.org On Sep 8, 2006, at 7:27 PM, Thomson, Martin wrote: > Can you see any problem with specifying a fast and efficient method > for calculating a centroid, but also permitting the use of more > sophisticated methods? I say this because every time the > performance argument is raised, up goes a little red flag. (Yes, > yes, it isn't all about performance). Yes, there are problems. If a server A uses max-area and passes a request to the centroid-using server B that serves sub-areas, you can get into trouble. Let's say that the max-area points to NY, but the centroid to NJ. The first server passes the request to the NY server, which uses centroids and now discovers that the service request is nowhere in NY, and returns an error. Bad news. Obviously, if the two metrics always agreed on the result, there wouldn't be a problem, but then there wouldn't be a reason to bother with the second algorithm. So far, I have not heard a convincing argument that max-area offers any realistic advantages for query areas that are usefully accurate for routing. You have convinced me that cell/face isn't good enough for routing, but that can't be fixed by using sophisticated max-area matching algorithms. Maybe you know the likely quick-fix accuracy; from http://www.sirf.com/Downloads/Collateral/GSC3(f)_6.20.05.pdf, it sounds like you can get 10 m within 1s, assisted, but that's obviously marketing literature, not measurement. > > For 1: I would say that the limited set of shapes in geo-shape > should be permitted. I would agree as long as somebody can convincingly point to real algorithms for centroid computation. No hand-waving allowed. > > For 3: I can see that forking would be a bad idea for a number of > reasons, I don't think that it should be encouraged. > Unfortunately, once you allow non-point matching, it's hard to avoid forking in a distributed system. Simple example, again using NY and NJ: while the state-discriminating server can determine whether a larger part of the query area is in NY and NJ, that says nothing about the county or city level. The query footprint could match all of a small town in NJ, while matching half a dozen towns in NY. The upstream server can't know that, so it has to pass the request to both states. You can construct arbitrarily complex scenarios along these lines. They will be relatively rare, but that just makes them harder to test for. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 08 21:10:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLrLz-0007Is-Vb; Fri, 08 Sep 2006 21:09:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLrLz-0007Ik-0e; Fri, 08 Sep 2006 21:09:51 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLrLv-0004Ul-3j; Fri, 08 Sep 2006 21:09:50 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 20:09:44 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Fri, 08 Sep 2006 20:09:44 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 20:09:44 -0500 Message-ID: From: "Winterbottom, James" To: "Marc Linsner" Date: Fri, 8 Sep 2006 20:09:41 -0500 Subject: RE: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 09 Sep 2006 01:09:44.0050 (UTC) FILETIME=[A27BDD20:01C6D3AC] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <001001c6d3a0$625b0c40$2b0d0d0a@amer.cisco.com> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy? Thread-Index: AcbTGV3rLC52tGDTSZGKsnPW07RXYgAVTGEAAAfyCUAAAOacsAAAYhNQAAAstRAAALMNEAABCiwwAAQ5khA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: geopriv@ietf.org, 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: , Errors-To: ecrit-bounces@ietf.org Marc, In all the examples used in RFC-3825 in the appendix, the way resolution is used is to express a range in the latitude, longitude and altitude. This expresses an area or volume, there is no other way to interpret this. I am past believing that you can't see this. I am not saying having a resolution parameter is not useful, just the way that RFC-3825 stipulates it be interpreted. As for errors please read PIDF-LO profile, it is very clear there. Cheers James > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Saturday, 9 September 2006 9:42 AM > To: Winterbottom, James > Cc: ecrit@ietf.org; geopriv@ietf.org > Subject: RE: [Ecrit] Location information in emergency > sessioninitiation,need for time and accuracy? >=20 > James, >=20 > We are obviously talking past each other. I used the aviation and marine > industries as examples of users of geo coordinates for their respective > navigation applications. I used that analogy because both those > applications commonly refer to fixed locations (e.g. airport runways, > marine > buoys/markers), the same non-mobile type entities served by RFC3825 (the > commonality being 'non-mobile, not the application). I can't testify > whether these application implementations internally represent data in > binary, octal, decimal, etc. But I can attest that these applications DO > NOT express any kind of uncertainty association in addition to the > location > representations. My experience with these applications have been with > variable length fields, hence a separate resolution parameter has not been > included. >=20 > Resolution, whether expressed in binary, octal, decimal, etc. cannot > represent an arbitrary area/shape. Hence, RFC3825 cannot express an > arbitrary area/shape as it only includes resolution. >=20 > Would you please expand your question concerning errors? What errors? >=20 > -Marc- >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: Friday, September 08, 2006 6:53 PM > > To: Marc Linsner > > Cc: ecrit@ietf.org; geopriv@ietf.org > > Subject: RE: [Ecrit] Location information in emergency > > sessioninitiation,need for time and accuracy? > > > > It is interesting that you point this out and I am certainly > > no expert in aviation and marine location systems. I will > > however point out that from what I have seen that searches at > > sea and for downed aircraft often span many thousands of > > square kilometres, I scarcely think that this would be > > acceptable in a domestic wired or wireless phone emergency situation. > > > > I would also point out that if you have used the same > > encoding as is used in those industries it behoves you to > > have put them in the references section of the RFC, and to > > have indicated that the encoding scheme came from the there > > in the text somewhere, I certainly couldn't find any. > > > > Now back to my initial series of questions: > > > > Point or Polygon, single answer please. > > How do you intend to address the concern regarding errors. > > > > Cheers > > James > > > > > > > -----Original Message----- > > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > > Sent: Saturday, 9 September 2006 8:29 AM > > > To: Winterbottom, James > > > Cc: ecrit@ietf.org; geopriv@ietf.org > > > Subject: RE: [Ecrit] Location information in emergency > > > sessioninitiation,need for time and accuracy? > > > > > > > > > > > > > > Marc, > > > > > > > > Perhaps the statement should have been, is not suitable for any > > > > application that require a deterministic degree of accuracy, > > > > something to that effect. > > > > I am quite sure that in some circumstances that the > > encoding scheme > > > > is fine, but I wouldn't want to be my life on it in an emergency, > > > > would you? > > > > > > I suggest emergency responders would have no problem > > finding locations > > > described by RFC3825, it's the same data expressions used > > by aviation > > and > > > marine everyday. So, unless you travel exclusively by rail, you've > > > probably already placed you life in the hands of such data > > > representation, I > > know I > > > have. > > > > > > -Marc- > > > > -------------------------------------------------------------- > > ---------------------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > -------------------------------------------------------------- > > ---------------------------------- > > [mf2] ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Sep 09 10:51:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GM4Ab-0003j3-Cn; Sat, 09 Sep 2006 10:50:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GM4AZ-0003iq-Hu; Sat, 09 Sep 2006 10:50:55 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GM4AX-0006uu-8n; Sat, 09 Sep 2006 10:50:55 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 09 Sep 2006 10:50:53 -0400 X-IronPort-AV: i="4.09,136,1157342400"; d="scan'208"; a="101540253:sNHT33095980" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k89Eoq5Z026127; Sat, 9 Sep 2006 10:50:52 -0400 Received: from [68.50.22.220] (che-vpn-cluster-2-182.cisco.com [10.86.242.182]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k89EoouI026295; Sat, 9 Sep 2006 10:50:50 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy? Date: Sat, 9 Sep 2006 10:50:46 -0400 To: "Winterbottom, James" X-Mailer: Apple Mail (2.624) DKIM-Signature: a=rsa-sha1; q=dns; l=2937; t=1157813452; x=1158677452; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jschnizl@cisco.com; z=From:John=20Schnizlein=20 |Subject:Re=3A=20[Ecrit]=20Location=20information=20in=20emergency=20sessioniniti ation,=20need=20for=20time=20and=20accuracy? |To:=22Winterbottom,=20James=22=20; X=v=3Dcisco.com=3B=20h=3DiqJrDvQ3r+LNFuEMj8tkFjFc+20=3D; b=e14EsNy93CPC2ewqYuQDTO5QCUdJU2iF/FnC63oqjB0m1zDJH1VeCkY95l/Ivnj0W42ZDl6r A3eO0hq2vNjp12cZhfSnTD5embGH3UeWKNBXtZpyi32LmN+RSuDzvpRb; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jschnizl@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: geopriv@ietf.org, 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: , Errors-To: ecrit-bounces@ietf.org On Sep 8, 2006, at 9:09 PM, Winterbottom, James wrote: > > In all the examples used in RFC-3825 in the appendix, the way > resolution > is used is to express a range in the latitude, longitude and altitude. > This expresses an area or volume, there is no other way to interpret > this. I am past believing that you can't see this. These illustrations are in an appendix to indicate that they are not normative. The point of the appendix is to show what size regions different resolutions imply, including deliberately partially hiding location by lowering resolution. This does not change the fact that the resolution is SPECIFIED as "number of valid bits in the fixed-point value". As we have explained before, this represents the normal scientific/engineering concept of significant figures. > I am not saying having a resolution parameter is not useful, just the > way that RFC-3825 stipulates it be interpreted. The way RFC 3825 specifies resolution is just what is necessary to implement the principle of significant figures when using a fixed-length binary number rather than a variable number (limited by the measurement precision) of decimal digits. > As for errors please read PIDF-LO profile, it is very clear there. No, it is not. As explained in the dialog on the GeoPriv list some time ago, the errors are in your interpretation of the illustration in the appendix of RFC 3825. RFC 3825 does not specify arbitrary geographic polygons, although you seem to insist it should. Your invention of longest matching substrings of boundaries leads to the errors you report. Please stop attributing your erroneous interpretation to the different purpose of RFC 3825. John >> From: Marc Linsner >> >> We are obviously talking past each other. I used the aviation and >> marine industries as examples of users of geo coordinates for their >> respective navigation applications. I used that analogy because both >> those applications commonly refer to fixed locations (e.g. airport >> runways, >> marine buoys/markers), the same non-mobile type entities served by >> RFC3825 >> (the commonality being 'non-mobile, not the application). I can't >> testify >> whether these application implementations internally represent data in >> binary, octal, decimal, etc. But I can attest that these applications >> DO NOT express any kind of uncertainty association in addition to the >> >> location representations. My experience with these applications have >> been with variable length fields, hence a separate resolution >> parameter >> has not been included. >> >> Resolution, whether expressed in binary, octal, decimal, etc. cannot >> represent an arbitrary area/shape. Hence, RFC3825 cannot express an >> arbitrary area/shape as it only includes resolution. >> >> Would you please expand your question concerning errors? What errors? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Sep 09 18:11:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMB2h-0000Pk-O8; Sat, 09 Sep 2006 18:11:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMB2f-0000Nf-Q1; Sat, 09 Sep 2006 18:11:13 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMB2f-0007Al-Fn; Sat, 09 Sep 2006 18:11:13 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Sep 2006 17:11:10 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Sat, 09 Sep 2006 17:11:09 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Sep 2006 17:10:42 -0500 Message-ID: From: "Winterbottom, James" To: "John Schnizlein" Date: Sat, 9 Sep 2006 17:11:07 -0500 Subject: RE: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 09 Sep 2006 22:10:42.0301 (UTC) FILETIME=[CA50CAD0:01C6D45C] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy? Thread-Index: AcbUH1oLlbGwRsnOSoymJDM7leqO2gAO2MGQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: geopriv@ietf.org, 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: , Errors-To: ecrit-bounces@ietf.org John, Please! Normal scientific measurements will say +- half the smallest unit. This will place a point in the middle somewhere, and you yourself at the very start of this debate came back with a proposal saying that.=20 The fact of the matter is that you are starting in the normative section of the draft that the resolutions parameters place you with in an area. If this is what is meant, then I am sorry to say that this but the PIDF-LO draft is correct and you are plain wrong! James Polk has stated more than once now that the shape defined in RFC-3825 is a linear ring polygon. If this is the case then the calculation in PIDF-LO profile also stand. Quite frankly what is it that RFC-3825 represents. This part of previous question you have tactfully ignored. So I am going to ask you. Point, or area? If Point, then a clarification draft stipulating this is required. If an area, then please provide a detailed explanation of how would re-describe the examples in PIDF-LO profile with references to the sections RFC-3825 that eliminate the inherent errors. I am tired of you saying that this is wrong, when it clearly follows your specification, and you do not provide through the same example where it is wrong, or provide a reasonable alternative. BR James > -----Original Message----- > From: John Schnizlein [mailto:jschnizl@cisco.com] > Sent: Sunday, 10 September 2006 12:51 AM > To: Winterbottom, James > Cc: geopriv@ietf.org; Marc Linsner; ecrit@ietf.org > Subject: Re: [Ecrit] Location information in emergency sessioninitiation, > need for time and accuracy? >=20 >=20 > On Sep 8, 2006, at 9:09 PM, Winterbottom, James wrote: > > > > In all the examples used in RFC-3825 in the appendix, the way > > resolution > > is used is to express a range in the latitude, longitude and altitude. > > This expresses an area or volume, there is no other way to interpret > > this. I am past believing that you can't see this. >=20 > These illustrations are in an appendix to indicate that they are not > normative. The point of the appendix is to show what size regions > different resolutions imply, including deliberately partially hiding > location by lowering resolution. This does not change the fact that > the resolution is SPECIFIED as "number of valid bits in the fixed-point > value". As we have explained before, this represents the normal > scientific/engineering concept of significant figures. >=20 > > I am not saying having a resolution parameter is not useful, just the > > way that RFC-3825 stipulates it be interpreted. >=20 > The way RFC 3825 specifies resolution is just what is necessary to > implement the principle of significant figures when using a > fixed-length binary number rather than a variable number (limited by > the measurement precision) of decimal digits. >=20 > > As for errors please read PIDF-LO profile, it is very clear there. >=20 > No, it is not. As explained in the dialog on the GeoPriv list some > time ago, the errors are in your interpretation of the illustration in > the appendix of RFC 3825. RFC 3825 does not specify arbitrary > geographic polygons, although you seem to insist it should. Your > invention of longest matching substrings of boundaries leads to the > errors you report. Please stop attributing your erroneous > interpretation to the different purpose of RFC 3825. >=20 > John >=20 > >> From: Marc Linsner > >> > >> We are obviously talking past each other. I used the aviation and > >> marine industries as examples of users of geo coordinates for their > >> respective navigation applications. I used that analogy because both > >> those applications commonly refer to fixed locations (e.g. airport > >> runways, > >> marine buoys/markers), the same non-mobile type entities served by > >> RFC3825 > >> (the commonality being 'non-mobile, not the application). I can't > >> testify > >> whether these application implementations internally represent data in > >> binary, octal, decimal, etc. But I can attest that these applications > >> DO NOT express any kind of uncertainty association in addition to the > >> > >> location representations. My experience with these applications have > >> been with variable length fields, hence a separate resolution > >> parameter > >> has not been included. > >> > >> Resolution, whether expressed in binary, octal, decimal, etc. cannot > >> represent an arbitrary area/shape. Hence, RFC3825 cannot express an > >> arbitrary area/shape as it only includes resolution. > >> > >> Would you please expand your question concerning errors? What errors? ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Sep 09 20:50:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMDVe-0003GO-Li; Sat, 09 Sep 2006 20:49:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMDVd-0003Fw-9u; Sat, 09 Sep 2006 20:49:17 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMDVb-0002M2-2t; Sat, 09 Sep 2006 20:49:17 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 09 Sep 2006 17:49:15 -0700 X-IronPort-AV: i="4.09,137,1157353200"; d="scan'208"; a="40814512:sNHT30584372" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8A0nE6H018446; Sat, 9 Sep 2006 20:49:14 -0400 Received: from [68.50.22.220] (che-vpn-cluster-2-182.cisco.com [10.86.242.182]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k8A0nCuI008736; Sat, 9 Sep 2006 20:49:12 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3b16f2ec895557379e48b424be6f0a12@cisco.com> Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy? Date: Sat, 9 Sep 2006 20:49:09 -0400 To: "Winterbottom, James" X-Mailer: Apple Mail (2.624) DKIM-Signature: a=rsa-sha1; q=dns; l=487; t=1157849354; x=1158713354; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jschnizl@cisco.com; z=From:John=20Schnizlein=20 |Subject:Re=3A=20[Ecrit]=20Location=20information=20in=20emergency=20sessioniniti ation,=20need=20for=20time=20and=20accuracy? |To:=22Winterbottom,=20James=22=20; X=v=3Dcisco.com=3B=20h=3DiqJrDvQ3r+LNFuEMj8tkFjFc+20=3D; b=btT+ENZgdSeHtzLTtH2qk1oj8n1N/K1mqAAfL2V0VQcosJQ6d2kiZNzNAb3HJksJK72z9ZVv k9Hf2gR5BD0V5RvxchYyci02nnw8XVwAoe+GcQnp23Pd4alyQCyow5Qm; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jschnizl@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: geopriv@ietf.org, 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: , Errors-To: ecrit-bounces@ietf.org What part of "geographic location of the client" is unclear to you? It is beyond comprehension how this could be interpreted as a area rather than a point, with the resolution of the measurement of that point explicitly included in the location information. Why is this old argument being rehashed in the ecrit WG when if finally seemed to die (mercifully) in GeoPriv? On Sep 9, 2006, at 6:11 PM, Winterbottom, James wrote: > So I am going to ask you. Point, or area? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Sep 09 21:02:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMDiL-0000LM-5z; Sat, 09 Sep 2006 21:02:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMDiJ-0000L1-G9; Sat, 09 Sep 2006 21:02:23 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMDiI-0006Gr-8p; Sat, 09 Sep 2006 21:02:23 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Sep 2006 20:02:21 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Sat, 09 Sep 2006 20:02:21 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Sep 2006 20:02:20 -0500 Message-ID: From: "Winterbottom, James" To: "John Schnizlein" Date: Sat, 9 Sep 2006 20:02:18 -0500 Subject: RE: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 10 Sep 2006 01:02:20.0776 (UTC) FILETIME=[C4AF5E80:01C6D474] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <3b16f2ec895557379e48b424be6f0a12@cisco.com> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy? Thread-Index: AcbUcvDwkNuQ6VLiQG2mB92eZip6LgAAYJfg X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: geopriv@ietf.org, 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: , Errors-To: ecrit-bounces@ietf.org So you are saying that the examples in the appendix of RFC-3825 are wrong, and that RFC-3825 cannot and never will describe an area? It didn't die in Geopriv, I was waiting for you to actual come back with an explanation, what you did was write back an email that was totally irrelevant to the discussion. So I am still waiting! > -----Original Message----- > From: John Schnizlein [mailto:jschnizl@cisco.com] > Sent: Sunday, 10 September 2006 10:49 AM > To: Winterbottom, James > Cc: geopriv@ietf.org; Marc Linsner; ecrit@ietf.org > Subject: Re: [Ecrit] Location information in emergency sessioninitiation, > need for time and accuracy? >=20 > What part of "geographic location of the client" is unclear to you? >=20 > It is beyond comprehension how this could be interpreted as a area > rather than a point, with the resolution of the measurement of that > point explicitly included in the location information. >=20 > Why is this old argument being rehashed in the ecrit WG when if finally > seemed to die (mercifully) in GeoPriv? >=20 > On Sep 9, 2006, at 6:11 PM, Winterbottom, James wrote: >=20 > > So I am going to ask you. Point, or area? ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Sep 09 23:23:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMFtj-0007jP-W3; Sat, 09 Sep 2006 23:22:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMFtj-0007jK-59 for ecrit@ietf.org; Sat, 09 Sep 2006 23:22:19 -0400 Received: from insmtp.indigital.net ([66.249.239.11] helo=inbsf.indigital.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMFti-00077G-No for ecrit@ietf.org; Sat, 09 Sep 2006 23:22:19 -0400 Received: from apa7.indigital.net (IP-66.249.239.5.indigital.net [66.249.239.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by inbsf.indigital.net (Spam Firewall) with ESMTP id 1FD9D2B8446 for ; Sat, 9 Sep 2006 23:22:03 -0400 (EDT) Received: from addr-66.249.235.119.nptpop-53cis03-dial-sub.rdns-bnin.net ([66.249.235.119] helo=[192.168.2.100]) by apa7.indigital.net with esmtpa (Exim 4.60) (envelope-from ) id 1GMFtQ-0001b7-PH for ecrit@ietf.org; Sat, 09 Sep 2006 23:22:02 -0400 Message-ID: <450384D4.6000903@indigital.net> Date: Sat, 09 Sep 2006 23:21:56 -0400 From: Byron Smith Organization: INdigital Telecom User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 CC: ecrit@ietf.org Subject: Re: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by INdigital SMTP Gateway at indigital.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bsmith@indigital.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org James, Your question: "Point or Area?" as well as your other comments the past couple of days about RFC-3825 seem to me to revel a real confusion on your part about the purpose and use of this standard. RFC-3825 is a *specification* of a standard way to *specify and code* geographic location information over a computer network. RFC-3825 permits the communication of x,y, and optionally z, coordinates with an accuracy of a few centimeters or better, *anywhere* on the face of the earth, including the equator, poles, or the meridians. RFC-3825 will work at the equator, in France, at the South pole, in the USA or Australia, or anywhere at sea. This is certainly *more than adequate* for any emergency purpose within the scope of these discussions. In this regard, x, y, and z are a *point.* Now, in the real world, anything that I specify will include some uncertainty or error. If I buy a beer, the container says: 12 fluid oz, 335 ml. But does the can contain *exactly* 335 ml? Maybe it only had 334.5 ml. Or 335.82 ml. Or 336.05723 ml. And when I drink it, did I drink exactly what was in the can? What about the residual drops left behind? The beer can would tell me more if it said: 335 ml +/- 5 ml. That would give me an idea if how accurately the container was filled. If I even care after I drink the beer! The beauty of RFC-3825 is that it not only lets me specify a point on the surface of the earth, but that it also allows me specify how precisely I think that I know where that point is located. Is the point accurate to within a few centimeters? A few meters? A few kilometers? The RFC lets me communicate this information. Now, some folks have been saying that this is an "area." That might be one way to think about it and describe it, but I suspect this this is a poor description. What is really being conveyed is some sort of probability distribution. Think of it this way: I want to specify a point on string. I might say: The point of interest is 1.5 meters from the left end of the string. This is clearly a point, but how accurately did I specify it? Do I mean the point is really at 1.5003 meters but you can't measure it that closely anyway, so 1.5 is good enough? Do I mean any spot on the string between 1.45 and 1.55 meters? Or did I mean exactly 1.5000000 meters? The original statement: "The point of interest is 1.5 meters from the left end of the string" doesn't speak to the issue of accuracy. But if I said: "The point of interest is 1.5 meters, +/- 0.05 meters" then you have a much better idea of where the point of interest really is on the string. Now, your question: Would you describe that point at 1.5 meters, +/- 0.05 meters, as a "Point" or as a "Line?" Quick, James, tell me... ***** It is possible to think of 1.5 meters, +/- 0.05 meters, as a line. But in reality, it is more of a probability distribution. If I wished to specify a line (on the string) I would probably say something like: The line starting at 1.4 meters and ending a 1.7 meters from the left end of the string. And, as before, this specifies a line, but tells you nothing about how accurately I want the line to marked out on the string. In order to specify a line with accuracy, I need to say something like this: The line from 1.4 meters, +/- 0.03 meters, to 1.7 meters, +/- 0.04 meters. **** This is the problem with thinking of the accuracy specification in RFC-3825 as an "area." That causes the confusion of "Point or Area?" and a whole lot of other confusions. RFC-3825 is a great way to specify or communicate a point on the surface of the earth. It also allows you to specify an accuracy associated with that communication. But if you want to specify an area, you need to send several points, that is, several RFC-3825 messages. Then, you can also communicate the accuracy of the *area* that you are communicating. **** Byron Winterbottom, James wrote: > So you are saying that the examples in the appendix of RFC-3825 are > wrong, and that RFC-3825 cannot and never will describe an area? > > It didn't die in Geopriv, I was waiting for you to actual come back with > an explanation, what you did was write back an email that was totally > irrelevant to the discussion. So I am still waiting! > > > > > >> -----Original Message----- >> From: John Schnizlein [mailto:jschnizl@cisco.com] >> Sent: Sunday, 10 September 2006 10:49 AM >> To: Winterbottom, James >> Cc: geopriv@ietf.org; Marc Linsner; ecrit@ietf.org >> Subject: Re: [Ecrit] Location information in emergency >> > sessioninitiation, > >> need for time and accuracy? >> >> What part of "geographic location of the client" is unclear to you? >> >> It is beyond comprehension how this could be interpreted as a area >> rather than a point, with the resolution of the measurement of that >> point explicitly included in the location information. >> >> Why is this old argument being rehashed in the ecrit WG when if >> > finally > >> seemed to die (mercifully) in GeoPriv? >> >> On Sep 9, 2006, at 6:11 PM, Winterbottom, James wrote: >> >> >>> So I am going to ask you. Point, or area? >>> > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Sep 09 23:29:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMG0C-0002Fs-Ng; Sat, 09 Sep 2006 23:29:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMG0B-0002Ff-Bn; Sat, 09 Sep 2006 23:28:59 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMG09-0007iL-2p; Sat, 09 Sep 2006 23:28:59 -0400 Received: from [10.0.1.50] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Sat, 09 Sep 2006 23:28:33 -0400 id 0158802A.45038661.00004DC7 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Date: Sat, 9 Sep 2006 23:28:38 -0400 To: Geopriv WG , "Ecrit@Ietf.Org" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: John Schnizlein Subject: [Ecrit] I'm 100% certain I Don't Understand 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: , Errors-To: ecrit-bounces@ietf.org At the risk of ending the cordial and praiseworthy correspondence of this thread, I would like to interject that I am fairly confused. Certainly (pun intended) I should have given much more attention to my math and statistics studies when I was younger. First, my initial confusion about this dealt with the terminology being used, which is somewhat a point of contention here. For the life of me, I could not understand why anybody would care to communicate their "uncertainty" regarding location information nor could I understand why a PSAP would want to know it. "The building I am in is on fire, but I'm only 50% certain that it is my house. I could be at work as well." That just doesn't make sense. So I can only gather that the word is being used in the context of statistical probability about a specific point within a shape. Is this correct? And can somebody point to an actual definition of the word? Is it the same as confidence as is used in probability? At looking at RFC 3825, I think there may be an issue with terminology but I believe the concept is appropriate. 3825 uses the term "resolution". I would have thought resolution would refer to the range of numbers allowed in the protocol fields. Instead, it is being used to describe the resolution of the measurement. That is fine. And the take away from it is that a point in 3 dimensions is being expressed. Now, if the receiver of this information is capable of understanding a higher "resolution", then one could start asking questions about the probability of where a point (at the receivers highest resolution) resides inside the shape that can be taken from the senders lower resolution point. I guess that might be useful if first responders are sent to the location given by the higher resolution point, find nothing, and are then advised to search a perimeter of a specific size. It turns out that the other document in this discussion does talk about this. From Section 6 of draft-ietf-geopriv-pdif-lo-profile: Generally these locations are expressed as a point (either in two or three dimensions) and an area or volume of uncertainty around the point. In theory, the area or volume represents a coverage in which the user has a relatively high probability of being found, and the point is a convenient means of defining the centroid for the area or volume. In practice, most systems use the point as an absolute value and ignore the uncertainty. Interchange "uncertainty" and "resolution" and these documents are saying the same thing. Which term is correct? At present, I'm not convinced either is. All this leaves me with two very big questions. Since 3825 is describing a point in 3 dimensions, why does pidf-lo-profile talk about 3825 LCI as being a rectangle in Appendix A? And if 3825 is describing a point, how can its equivalent in GML be a linear ring? I would think it would be a GML point (or Position in GML speak). -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Sep 10 00:57:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMHNT-0005wF-Gr; Sun, 10 Sep 2006 00:57:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMHNS-0005wA-IH for ecrit@ietf.org; Sun, 10 Sep 2006 00:57:06 -0400 Received: from insmtp.indigital.net ([66.249.239.11] helo=inbsf.indigital.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMHNQ-0003qc-3U for ecrit@ietf.org; Sun, 10 Sep 2006 00:57:06 -0400 Received: from apa8.indigital.net (IP-66.249.239.5.indigital.net [66.249.239.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by inbsf.indigital.net (Spam Firewall) with ESMTP id 930072B7C83 for ; Sun, 10 Sep 2006 00:56:53 -0400 (EDT) Received: from addr-66.249.235.119.nptpop-53cis03-dial-sub.rdns-bnin.net ([66.249.235.119] helo=[192.168.2.100]) by apa8.indigital.net with esmtpa (Exim 4.60) (envelope-from ) id 1GMHND-0005DQ-2E for ecrit@ietf.org; Sun, 10 Sep 2006 00:56:53 -0400 Message-ID: <45039B12.3040305@indigital.net> Date: Sun, 10 Sep 2006 00:56:50 -0400 From: Byron Smith Organization: INdigital Telecom User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 CC: "Ecrit@Ietf.Org" Subject: Re: [Ecrit] I'm 100% certain I Don't Understand References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by INdigital SMTP Gateway at indigital.net X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bsmith@indigital.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Andrew Newton wrote: > At the risk of ending the cordial and praiseworthy correspondence of > this thread, I would like to interject that I am fairly confused. > Certainly (pun intended) I should have given much more attention to my > math and statistics studies when I was younger. > > First, my initial confusion about this dealt with the terminology > being used, which is somewhat a point of contention here. For the > life of me, I could not understand why anybody would care to > communicate their "uncertainty" regarding location information nor > could I understand why a PSAP would want to know it. "The building I > am in is on fire, but I'm only 50% certain that it is my house. I > could be at work as well." That just doesn't make sense. In the case of a house, the position of the house should have been determined accurately enough so that the PSAP can plot the location on a map and dispatch to the correct civil address. And the PSAP wouldn't care about any "uncertainty." However, the position determining systems presently used by some wireless carriers / commercial mobile radio service (CRMS) providers vary considerably in their ability to render an accurate fix of the caller's location. This is especially true of "network-based" angle / time of arrival systems. The distance of the caller from the tower, the presence of objects (like large buildings) that reflect the radio signal, and the geometry of the location between towers in triangulation systems, can cause the accuracy of the fix to vary greatly. In these cases, it may be very helpful to the PSAP to have an estimate of the uncertainty of the fix. If they dispatch to the caller's reported location and cannot find the caller, then the uncertainty may help them decide if they should search +/- 1000 feet, +/- two miles, etc. from the fix. So it may help them bound the search area. > So I can only gather that the word is being used in the context of > statistical probability about a specific point within a shape. Is > this correct? And can somebody point to an actual definition of the > word? Is it the same as confidence as is used in probability? When an uncertainty is reported, it means there is a certain probability that the actual value is within the expressed interval. The actual probability may be explicitly expressed: n +/-e with 67 % probability, or it may be implied by convention (typically 95%) or as a "known" characteristic of the system. For example, FCC Phase II requirements for handset-based wireless location systems is that the reported position is accurate +/- 50 meters 67% of the time, +/- 150 meters 95% of the time. In such cases, only the lat/long need be reported. For those 5% of the calls that are outside of the 150 meter requirement: "location attempts must be made and a location estimate for each call must be provided to the appropriate PSAP." (Title 47, Part 20, Sec 18 h (3).) How the system would determine if the call falls into the 5% case is not clear. Most systems report an "uncertainty" with every call, even though (in principle) it is not required 95% of the time, assuming the system meets the FCC requirements. > > At looking at RFC 3825, I think there may be an issue with terminology > but I believe the concept is appropriate. 3825 uses the term > "resolution". I would have thought resolution would refer to the > range of numbers allowed in the protocol fields. Instead, it is being > used to describe the resolution of the measurement. That is fine. > And the take away from it is that a point in 3 dimensions is being > expressed. Correct. The "significant digits" in the protocol fields may reflect the resolution of the measurement or of the report, whichever is lower. To the receiver these are essentially equivalent views. For example, if I can measure some value as xx.xx +/- 0.005, but report: 45.343612, everything after 45.34 is just "noise." The sender should not report more than 4 significant digits, since anything more is meaningless, or, the receiver should ignore everything after the 45.34, if it "knows" the resolution is 4 significant digits. Conversely if I measure 45.343612, but report a resolution of 4 significant digits, the receiver must regard the measurement as no better than 45.34 +/- 0.005. > > Now, if the receiver of this information is capable of understanding a > higher "resolution", then one could start asking questions about the > probability of where a point (at the receivers highest resolution) > resides inside the shape that can be taken from the senders lower > resolution point. I guess that might be useful if first responders > are sent to the location given by the higher resolution point, find > nothing, and are then advised to search a perimeter of a specific size. Actually, the receiver should not assume the higher resolution initially. > > It turns out that the other document in this discussion does talk > about this. From Section 6 of draft-ietf-geopriv-pdif-lo-profile: > > Generally these locations are expressed as a point > (either in two or three dimensions) and an area or volume of > uncertainty around the point. In theory, the area or volume > represents a coverage in which the user has a relatively high > probability of being found, and the point is a convenient means of > defining the centroid for the area or volume. In practice, most > systems use the point as an absolute value and ignore the > uncertainty. > > Interchange "uncertainty" and "resolution" and these documents are > saying the same thing. Which term is correct? At present, I'm not > convinced either is. Uncertainty is usually expressed as an "interval", e.g. +/- e. Resolution is usually expressed as "number of significant digits," e.g. 3 1/2 digits. RFC-3825 properly describes its expression of accuracy as "resolution," because it is telling you how many digits in the lat/long can be "counted." On the other hand, most CMRS systems report "uncertainty" to the PSAP. It is fairly straightforward to convert between these two notations. So these documents really are saying the same thing. > > All this leaves me with two very big questions. Since 3825 is > describing a point in 3 dimensions, why does pidf-lo-profile talk > about 3825 LCI as being a rectangle in Appendix A? The terminology in the Appendix should probably be improved. It isn't really a geometric object, it is a (derived) uncertainty range or interval > And if 3825 is describing a point, how can its equivalent in GML be a > linear ring? I would think it would be a GML point (or Position in > GML speak). > > -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 Sun Sep 10 04:32:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMKj9-0000kp-Uq; Sun, 10 Sep 2006 04:31:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMKj8-0000k6-Sv for ecrit@ietf.org; Sun, 10 Sep 2006 04:31:42 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMKj8-0000wg-Ee for ecrit@ietf.org; Sun, 10 Sep 2006 04:31:42 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 10 Sep 2006 03:31:30 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Sun, 10 Sep 2006 03:31:30 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 10 Sep 2006 03:31:29 -0500 Message-ID: From: "Winterbottom, James" To: Date: Sun, 10 Sep 2006 03:31:26 -0500 Subject: RE: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 10 Sep 2006 08:31:29.0603 (UTC) FILETIME=[83700930:01C6D4B3] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <450384D4.6000903@indigital.net> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy? Thread-Index: AcbUiOQbS3OKI7JIQCqzZDz9W1cVjwAKRKLw X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 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: , Errors-To: ecrit-bounces@ietf.org Byron, This debate began at the GeoPriv interim meeting in May of last year. I indicated that the DHCP representation was not a solution that would accommodate all location representation because it only represented a point. This argument was subsequently refuted very intensely by James Polk that insisted that the encoding in RFC-3825 represented a rectangle or prism. We have subsequently shown that the encoding scheme is not suitable for representing this is a wide degree of circumstances. I think it perfectly acceptable for point representation. The problem with RFC-3825 is that nearly all the examples in the appendix, which are the things that most implementers will follow, are misleading in this interpretation at best as they all describe areas, and not points. For RFC-3825 to be acceptable for emergency services it should be restricted to representing what it can adequately represent and not be used to represent location that it is quite clearly not fit for, i.e anything that is not a simple point. The RFC on this point is far from clear, and I am suggesting that the authors and supporters of this specification write a clarifying proposal describing its useability and applicability to emergency applications. Regards James. > -----Original Message----- > From: Byron Smith [mailto:bsmith@indigital.net] > Sent: Sunday, 10 September 2006 1:22 PM > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Location information in emergency > sessioninitiation,need for time and accuracy? >=20 > James, >=20 > Your question: "Point or Area?" as well as your other comments the past > couple of days about RFC-3825 seem to me to revel a real confusion on > your part about the purpose and use of this standard. >=20 > RFC-3825 is a *specification* of a standard way to *specify and code* > geographic location information over a computer network. >=20 > RFC-3825 permits the communication of x,y, and optionally z, coordinates > with an accuracy of a few centimeters or better, *anywhere* on the face > of the earth, including the equator, poles, or the meridians. RFC-3825 > will work at the equator, in France, at the South pole, in the USA or > Australia, or anywhere at sea. This is certainly *more than adequate* > for any emergency purpose within the scope of these discussions. >=20 > In this regard, x, y, and z are a *point.* >=20 > Now, in the real world, anything that I specify will include some > uncertainty or error. >=20 > If I buy a beer, the container says: 12 fluid oz, 335 ml. >=20 > But does the can contain *exactly* 335 ml? Maybe it only had 334.5 ml. > Or 335.82 ml. Or 336.05723 ml. And when I drink it, did I drink > exactly what was in the can? What about the residual drops left behind? >=20 > The beer can would tell me more if it said: 335 ml +/- 5 ml. That > would give me an idea if how accurately the container was filled. If I > even care after I drink the beer! >=20 > The beauty of RFC-3825 is that it not only lets me specify a point on > the surface of the earth, but that it also allows me specify how > precisely I think that I know where that point is located. Is the point > accurate to within a few centimeters? A few meters? A few kilometers? > The RFC lets me communicate this information. >=20 > Now, some folks have been saying that this is an "area." That might be > one way to think about it and describe it, but I suspect this this is a > poor description. What is really being conveyed is some sort of > probability distribution. >=20 > Think of it this way: I want to specify a point on string. I might > say: The point of interest is 1.5 meters from the left end of the > string. >=20 > This is clearly a point, but how accurately did I specify it? Do I mean > the point is really at 1.5003 meters but you can't measure it that > closely anyway, so 1.5 is good enough? Do I mean any spot on the string > between 1.45 and 1.55 meters? Or did I mean exactly 1.5000000 meters? > The original statement: "The point of interest is 1.5 meters from the > left end of the string" doesn't speak to the issue of accuracy. >=20 > But if I said: "The point of interest is 1.5 meters, +/- 0.05 meters" > then you have a much better idea of where the point of interest really > is on the string. >=20 > Now, your question: Would you describe that point at 1.5 meters, +/- > 0.05 meters, as a "Point" or as a "Line?" Quick, James, tell me... >=20 > ***** >=20 > It is possible to think of 1.5 meters, +/- 0.05 meters, as a line. But > in reality, it is more of a probability distribution. >=20 > If I wished to specify a line (on the string) I would probably say > something like: The line starting at 1.4 meters and ending a 1.7 meters > from the left end of the string. >=20 > And, as before, this specifies a line, but tells you nothing about how > accurately I want the line to marked out on the string. >=20 > In order to specify a line with accuracy, I need to say something like > this: The line from 1.4 meters, +/- 0.03 meters, to 1.7 meters, +/- > 0.04 meters. >=20 > **** >=20 > This is the problem with thinking of the accuracy specification in > RFC-3825 as an "area." That causes the confusion of "Point or Area?" > and a whole lot of other confusions. >=20 > RFC-3825 is a great way to specify or communicate a point on the surface > of the earth. It also allows you to specify an accuracy associated with > that communication. >=20 > But if you want to specify an area, you need to send several points, > that is, several RFC-3825 messages. Then, you can also communicate the > accuracy of the *area* that you are communicating. >=20 > **** >=20 > Byron >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Winterbottom, James wrote: > > So you are saying that the examples in the appendix of RFC-3825 are > > wrong, and that RFC-3825 cannot and never will describe an area? > > > > It didn't die in Geopriv, I was waiting for you to actual come back with > > an explanation, what you did was write back an email that was totally > > irrelevant to the discussion. So I am still waiting! > > > > > > > > > > > >> -----Original Message----- > >> From: John Schnizlein [mailto:jschnizl@cisco.com] > >> Sent: Sunday, 10 September 2006 10:49 AM > >> To: Winterbottom, James > >> Cc: geopriv@ietf.org; Marc Linsner; ecrit@ietf.org > >> Subject: Re: [Ecrit] Location information in emergency > >> > > sessioninitiation, > > > >> need for time and accuracy? > >> > >> What part of "geographic location of the client" is unclear to you? > >> > >> It is beyond comprehension how this could be interpreted as a area > >> rather than a point, with the resolution of the measurement of that > >> point explicitly included in the location information. > >> > >> Why is this old argument being rehashed in the ecrit WG when if > >> > > finally > > > >> seemed to die (mercifully) in GeoPriv? > >> > >> On Sep 9, 2006, at 6:11 PM, Winterbottom, James wrote: > >> > >> > >>> So I am going to ask you. Point, or area? > >>> > > > > ------------------------------------------------------------------------ > ------------------------ > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > ------------------------------------------------------------------------ > ------------------------ > > [mf2] > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Sep 10 10:01:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMPru-0008Ds-3x; Sun, 10 Sep 2006 10:01:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMPrs-0008De-Kv for ecrit@ietf.org; Sun, 10 Sep 2006 10:01:04 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMPrr-0000Kj-6Z for ecrit@ietf.org; Sun, 10 Sep 2006 10:01:04 -0400 Received: from [192.168.0.41] (pool-141-153-175-20.mad.east.verizon.net [141.153.175.20]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k8AE0rGl016250 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sun, 10 Sep 2006 10:00:53 -0400 (EDT) In-Reply-To: <45039B12.3040305@indigital.net> References: <45039B12.3040305@indigital.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3286E5BC-3D59-46AF-ADC9-3A352F9B9CBC@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] I'm 100% certain I Don't Understand Date: Sun, 10 Sep 2006 10:00:45 -0400 To: bsmith@indigital.net X-Mailer: Apple Mail (2.752.2) X-PerlMx-Spam: Gauge=XXII, Probability=22%, X-Seen-By filter1.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e 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: , Errors-To: ecrit-bounces@ietf.org This is getting more helpful, rather than just making assertions. Without precise, accurate, and agreed-upon recognized terminology, we're not going to get very far in this. See http://en.wikipedia.org/wiki/Accuracy for one accessible treatment that seems reasonable. To make matters worse, the probability region is often of constant size, even though the PSAP doesn't really care as to whether localization technique X has a 95% uncertainty region of 100 m when averaged across the United States, but rather what the likely region is for the caller in a very specific place. For the reasons mentioned, for TOA and similar techniques, errors do not have the same distribution everywhere. I'm not a GPS expert, but I believe it's a bit more uniform for GPS, but with some time-of-day dependencies due to ionization differences in the atmosphere. In any specific place, you are likely to have both systematic (non- zero-mean) and random (zero-mean) errors, i.e., the most likely location may not be in the middle of the uncertainty region for most places. Indeed, in a specific place, the target may *always* be outside the region described. Thus, without a lot of additional qualifications, the implied preciseness of a geometric region of whatever shape may well be more comforting than real. I have to admit that I find the point vs. area discussion more in the spirit of scoring debating points than illuminating. May I suggest that the interested parties work together, behind the scenes, on a set of definitions that are based on common technical usage and then get back to the rest of us? Public email sniping in front of an audience of hundreds seems unlikely to produce accuracy or precision or confidence. Henning On Sep 10, 2006, at 12:56 AM, Byron Smith wrote: > Andrew Newton wrote: >> At the risk of ending the cordial and praiseworthy correspondence >> of this thread, I would like to interject that I am fairly >> confused. Certainly (pun intended) I should have given much more >> attention to my math and statistics studies when I was younger. >> >> First, my initial confusion about this dealt with the terminology >> being used, which is somewhat a point of contention here. For the >> life of me, I could not understand why anybody would care to >> communicate their "uncertainty" regarding location information nor >> could I understand why a PSAP would want to know it. "The >> building I am in is on fire, but I'm only 50% certain that it is >> my house. I could be at work as well." That just doesn't make >> sense. > In the case of a house, the position of the house should have been > determined accurately enough so that the PSAP can plot the location > on a map and dispatch to the correct civil address. And the PSAP > wouldn't care about any "uncertainty." > > However, the position determining systems presently used by some > wireless carriers / commercial mobile radio service (CRMS) > providers vary considerably in their ability to render an accurate > fix of the caller's location. This is especially true of "network- > based" angle / time of arrival systems. The distance of the caller > from the tower, the presence of objects (like large buildings) that > reflect the radio signal, and the geometry of the location between > towers in triangulation systems, can cause the accuracy of the fix > to vary greatly. > In these cases, it may be very helpful to the PSAP to have an > estimate of the uncertainty of the fix. If they dispatch to the > caller's reported location and cannot find the caller, then the > uncertainty may help them decide if they should search +/- 1000 > feet, +/- two miles, etc. from the fix. So it may help them bound > the search area. >> So I can only gather that the word is being used in the context of >> statistical probability about a specific point within a shape. Is >> this correct? And can somebody point to an actual definition of >> the word? Is it the same as confidence as is used in probability? > When an uncertainty is reported, it means there is a certain > probability that the actual value is within the expressed > interval. The actual probability may be explicitly expressed: n > +/-e with 67 % probability, or it may be implied by convention > (typically 95%) or as a "known" characteristic of the system. > > For example, FCC Phase II requirements for handset-based wireless > location systems is that the reported position is accurate +/- 50 > meters 67% of the time, +/- 150 meters 95% of the time. In such > cases, only the lat/long need be reported. > For those 5% of the calls that are outside of the 150 meter > requirement: "location attempts must be made and a location > estimate for each call must be provided to the appropriate > PSAP." (Title 47, Part 20, Sec 18 h (3).) > > How the system would determine if the call falls into the 5% case > is not clear. Most systems report an "uncertainty" with every > call, even though (in principle) it is not required 95% of the > time, assuming the system meets the FCC requirements. >> >> At looking at RFC 3825, I think there may be an issue with >> terminology but I believe the concept is appropriate. 3825 uses >> the term "resolution". I would have thought resolution would >> refer to the range of numbers allowed in the protocol fields. >> Instead, it is being used to describe the resolution of the >> measurement. That is fine. And the take away from it is that a >> point in 3 dimensions is being expressed. > Correct. > The "significant digits" in the protocol fields may reflect the > resolution of the measurement or of the report, whichever is lower. > > To the receiver these are essentially equivalent views. For > example, if I can measure some value as xx.xx +/- 0.005, but > report: 45.343612, everything after 45.34 is just "noise." The > sender should not report more than 4 significant digits, since > anything more is meaningless, or, the receiver should ignore > everything after the 45.34, if it "knows" the resolution is 4 > significant digits. > > Conversely if I measure 45.343612, but report a resolution of 4 > significant digits, the receiver must regard the measurement as no > better than 45.34 +/- 0.005. >> >> Now, if the receiver of this information is capable of >> understanding a higher "resolution", then one could start asking >> questions about the probability of where a point (at the receivers >> highest resolution) resides inside the shape that can be taken >> from the senders lower resolution point. I guess that might be >> useful if first responders are sent to the location given by the >> higher resolution point, find nothing, and are then advised to >> search a perimeter of a specific size. > Actually, the receiver should not assume the higher resolution > initially. >> >> It turns out that the other document in this discussion does talk >> about this. From Section 6 of draft-ietf-geopriv-pdif-lo-profile: >> >> Generally these locations are expressed as a point >> (either in two or three dimensions) and an area or volume of >> uncertainty around the point. In theory, the area or volume >> represents a coverage in which the user has a relatively high >> probability of being found, and the point is a convenient means of >> defining the centroid for the area or volume. In practice, most >> systems use the point as an absolute value and ignore the >> uncertainty. >> >> Interchange "uncertainty" and "resolution" and these documents are >> saying the same thing. Which term is correct? At present, I'm >> not convinced either is. > Uncertainty is usually expressed as an "interval", e.g. +/- e. > Resolution is usually expressed as "number of significant digits," > e.g. 3 1/2 digits. RFC-3825 properly describes its expression of > accuracy as "resolution," because it is telling you how many digits > in the lat/long can be "counted." On the other hand, most CMRS > systems report "uncertainty" to the PSAP. > It is fairly straightforward to convert between these two > notations. So these documents really are saying the same thing. >> >> All this leaves me with two very big questions. Since 3825 is >> describing a point in 3 dimensions, why does pidf-lo-profile talk >> about 3825 LCI as being a rectangle in Appendix A? > The terminology in the Appendix should probably be improved. It > isn't really a geometric object, it is a (derived) uncertainty > range or interval >> And if 3825 is describing a point, how can its equivalent in GML >> be a linear ring? I would think it would be a GML point (or >> Position in GML speak). >> >> -andy >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Sep 10 12:25:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMS6X-0004zA-0t; Sun, 10 Sep 2006 12:24:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMS6V-0004z4-JL for ecrit@ietf.org; Sun, 10 Sep 2006 12:24:19 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMS6S-0004TI-7w for ecrit@ietf.org; Sun, 10 Sep 2006 12:24:19 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 10 Sep 2006 09:24:15 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8AGOFqe020097; Sun, 10 Sep 2006 09:24:15 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8AGODQV007946; Sun, 10 Sep 2006 09:24:13 -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.1830); Sun, 10 Sep 2006 09:24:13 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 10 Sep 2006 09:24:10 -0700 From: "Marc Linsner" To: "'Winterbottom, James'" Subject: RE: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy? Date: Sun, 10 Sep 2006 12:24:06 -0400 Message-ID: <005501c6d4f5$8b47eaa0$2b0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: Thread-Index: AcbUiOQbS3OKI7JIQCqzZDz9W1cVjwAKRKLwABB6pGA= X-OriginalArrivalTime: 10 Sep 2006 16:24:12.0836 (UTC) FILETIME=[8D3DEE40:01C6D4F5] DKIM-Signature: a=rsa-sha1; q=dns; l=984; t=1157905455; x=1158769455; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=22Marc=20Linsner=22=20 |Subject:RE=3A=20[Ecrit]=20Location=20information=20in=20emergency=20sessioniniti ation,need=20for=20time=20and=20accuracy?; X=v=3Dcisco.com=3B=20h=3D7hpF0EWyVRhTJBXGzZIFNFAT5v8=3D; b=tO4mb/AKuapINZPcChal9hyrwICNq9MxMLdTlj2MiD9o/ZvmCx33D6rM4wKlyVhk14B0xVHS G/nfkTBamDTD8o7US7SFNiYxchaOCRgJxAhPROEUybtj5RRDMIzi2DMT; Authentication-Results: sj-dkim-2.cisco.com; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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: , Errors-To: ecrit-bounces@ietf.org James, > For RFC-3825 to be acceptable for emergency services it > should be restricted to representing what it can adequately > represent and not be used to represent location that it is > quite clearly not fit for, i.e anything that is not a simple > point. The RFC on this point is far from clear, and I am > suggesting that the authors and supporters of this > specification write a clarifying proposal describing its > useability and applicability to emergency applications. You continually propose that emergency services are different wrt using geo coordinates. There is nothing special about emergency services, geo coordinates describing a point IS the target technology that emergency responders need/want. I have little experience inside a psap, but on the occasion I have visited one, I asked the call taker about the confidence included with Phase II calls. Most call takers don't know what it is, and those that do, ignore it. -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Sep 10 18:27:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMXkg-0001ae-RB; Sun, 10 Sep 2006 18:26:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMXkf-0001Yg-Sj for ecrit@ietf.org; Sun, 10 Sep 2006 18:26:09 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMXkd-0003LB-K2 for ecrit@ietf.org; Sun, 10 Sep 2006 18:26:09 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 10 Sep 2006 17:26:02 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Sun, 10 Sep 2006 17:26:02 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 10 Sep 2006 17:26:02 -0500 Message-ID: From: "Winterbottom, James" To: "Marc Linsner" Date: Sun, 10 Sep 2006 17:25:59 -0500 Subject: RE: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 10 Sep 2006 22:26:02.0044 (UTC) FILETIME=[18F02FC0:01C6D528] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <005501c6d4f5$8b47eaa0$2b0d0d0a@amer.cisco.com> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy? Thread-Index: AcbUiOQbS3OKI7JIQCqzZDz9W1cVjwAKRKLwABB6pGAADM5kcA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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: , Errors-To: ecrit-bounces@ietf.org Again I think you are confusing the terms confidence and uncertainty. Please see Martin's previous email. In the US, almost no two PSAPs are the same, and there are certainly PSAPs in the US that have systems capable of displaying uncertainty areas to PSAP operators. As I pointed out to you off the list, the key difference between emergency services and other services is that there is legislation requiring the degree of accuracy, consequently as an access provider you need to make sure that you can meet them. Cheers James=20 > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Monday, 11 September 2006 2:24 AM > To: Winterbottom, James > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Location information in emergency > sessioninitiation,need for time and accuracy? >=20 > James, >=20 > > For RFC-3825 to be acceptable for emergency services it > > should be restricted to representing what it can adequately > > represent and not be used to represent location that it is > > quite clearly not fit for, i.e anything that is not a simple > > point. The RFC on this point is far from clear, and I am > > suggesting that the authors and supporters of this > > specification write a clarifying proposal describing its > > useability and applicability to emergency applications. >=20 > You continually propose that emergency services are different wrt using > geo > coordinates. There is nothing special about emergency services, geo > coordinates describing a point IS the target technology that emergency > responders need/want. >=20 > I have little experience inside a psap, but on the occasion I have visited > one, I asked the call taker about the confidence included with Phase II > calls. Most call takers don't know what it is, and those that do, ignore > it. >=20 > -Marc- ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 11 05:03:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMhgn-0002GF-HR; Mon, 11 Sep 2006 05:02:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMhgN-0001cI-4E; Mon, 11 Sep 2006 05:02:23 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMhgD-0004Tg-0G; Mon, 11 Sep 2006 05:02:23 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Sep 2006 04:02:12 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Mon, 11 Sep 2006 04:02:12 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Sep 2006 04:02:11 -0500 Message-ID: From: "Winterbottom, James" To: Date: Mon, 11 Sep 2006 04:02:09 -0500 Subject: RE: [Geopriv] RE: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 11 Sep 2006 09:02:11.0701 (UTC) FILETIME=[F7D3A250:01C6D580] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <3086.218.208.53.35.1157963762.squirrel@mail.opengeospatial.org> Content-class: urn:content-classes:message Thread-Topic: [Geopriv] RE: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy? Thread-Index: AcbVfV5qqSx3y7LMRJWVpJrhuAc7zAAArZGw X-Spam-Score: 0.6 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: geopriv@ietf.org, ecrit@ietf.org, John Schnizlein 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: , Errors-To: ecrit-bounces@ietf.org Hi Carl, Thanks for the input. I guess as far as I see it, this should go one of two ways. Either, stipulate RFC-3825 as representing a point only, in which case a specification is required to make this clear and unambiguous. Or A specification is required expressing how to interpret the encoding scheme such that the problems around the equator, prime meridian and other arbitrary locations are not encountered. I don't mind which, but a problem exist and supporters of the RFC-3825 mechanism should seek to resolve it. Until such time as it is resolved this specification should only be used with a great deal of caution. Cheers James > -----Original Message----- > From: creed@opengeospatial.org [mailto:creed@opengeospatial.org] > Sent: Monday, 11 September 2006 6:36 PM > To: Winterbottom, James > Cc: John Schnizlein; geopriv@ietf.org; Marc Linsner; ecrit@ietf.org > Subject: Re: [Geopriv] RE: [Ecrit] Location information in emergency > sessioninitiation, need for time and accuracy? >=20 > This conversation peaked my interest. I have just looked at RFC-3825. Not > having been privy to all the original discussions and decisions, I am a > fresh set of "eyes" looking at this document. I think what we have here is > a failure to communicate due to ambiguous semantics in 3825. I may be > wrong in this perception, but . . . >=20 > My interpretation is that what is being defined is a uncertainty shape in > which the location of the device falls. As such, it is not truly a point. > A point in Euclidean geometry has no size, orientation, or any other > feature except position. This is the basis of the ISO/OGC definition for a > point geometry. >=20 > Take the following example. We draw a point by placing a dot with a > pencil. This dot may have a diameter of 0.2mm, but a point has no size. No > matter how far you zoomed in, it would still have no width. >=20 > What this discussion is really about is the fact that a point geometry, > whose location is defined by a lat/long coordinate, also has properties. > These properties include estimates of accuracy and precision. Very simply > stated: If the actual value is 4.321 and you say that it is 4.30, then you > are precise to the first decimal place but inaccurate by .021. There are > also properties of error and uncertainty. All these four properties are > very well defined in the literature. For example see: > http://scidiv.bcc.ctc.edu/Physics/Measure&sigfigs/B-Acc-Prec-Unc.html >=20 > So, what I would suggest is that perhaps 3825 be modified to very clearly > disambiguate the semantics of the terms being used. I suspect that what > "resolution" is really referring to is a description of the uncertainty of > the measurement. The point being measured falls somewhere in the area of > certainty. The shape of this area (yes, it is an area/polygon) actually > has a pretty strange shape if one transforms from lat/long to some other > coordinate reference system, such as State Plane. >=20 > Regards >=20 > Carl >=20 >=20 > > So you are saying that the examples in the appendix of RFC-3825 are > > wrong, and that RFC-3825 cannot and never will describe an area? > > > > It didn't die in Geopriv, I was waiting for you to actual come back with > > an explanation, what you did was write back an email that was totally > > irrelevant to the discussion. So I am still waiting! > > > > > > > > > > > >> -----Original Message----- > >> From: John Schnizlein [mailto:jschnizl@cisco.com] > >> Sent: Sunday, 10 September 2006 10:49 AM > >> To: Winterbottom, James > >> Cc: geopriv@ietf.org; Marc Linsner; ecrit@ietf.org > >> Subject: Re: [Ecrit] Location information in emergency > > sessioninitiation, > >> need for time and accuracy? > >> > >> What part of "geographic location of the client" is unclear to you? > >> > >> It is beyond comprehension how this could be interpreted as a area > >> rather than a point, with the resolution of the measurement of that > >> point explicitly included in the location information. > >> > >> Why is this old argument being rehashed in the ecrit WG when if > > finally > >> seemed to die (mercifully) in GeoPriv? > >> > >> On Sep 9, 2006, at 6:11 PM, Winterbottom, James wrote: > >> > >> > So I am going to ask you. Point, or area? > > > > ------------------------------------------------------------------------ > ------------------------ > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > ------------------------------------------------------------------------ > ------------------------ > > [mf2] > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > >=20 >=20 ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 11 10:20:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMmdT-00036E-HD; Mon, 11 Sep 2006 10:19:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMmdS-00035t-7Y; Mon, 11 Sep 2006 10:19:42 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMmdQ-0002Lu-T0; Mon, 11 Sep 2006 10:19:42 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 11 Sep 2006 07:19:41 -0700 X-IronPort-AV: i="4.09,146,1157353200"; d="scan'208"; a="319852473:sNHT33897622" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8BEJeIX006614; Mon, 11 Sep 2006 07:19:40 -0700 Received: from [10.10.10.212] (sjc-vpn2-738.cisco.com [10.21.114.226]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k8BEJbw7001599; Mon, 11 Sep 2006 07:19:39 -0700 (PDT) In-Reply-To: <3086.218.208.53.35.1157963762.squirrel@mail.opengeospatial.org> References: <3b16f2ec895557379e48b424be6f0a12@cisco.com> <3086.218.208.53.35.1157963762.squirrel@mail.opengeospatial.org> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: [Geopriv] RE: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy? Date: Mon, 11 Sep 2006 10:19:40 -0400 To: creed@opengeospatial.org X-Mailer: Apple Mail (2.624) DKIM-Signature: a=rsa-sha1; q=dns; l=3101; t=1157984380; x=1158848380; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jschnizl@cisco.com; z=From:John=20Schnizlein=20 |Subject:Re=3A=20[Geopriv]=20RE=3A=20[Ecrit]=20Location=20information=20in=20emer gency=20=20sessioninitiation,=20need=20for=20time=20and=20accuracy?; X=v=3Dcisco.com=3B=20h=3DPXYtkYxFinjFm/dJ0pLaUwpqHKA=3D; b=Ja3V4E0cZzdmv5NmIBKf3qQjDF76WXpzA5mDkbwn415aTPPtXVkwtdBCf5nNYA6O+ltMfxPw evM7IoD3LXghD3g23zGot3Iq76xOOnpEnkGgiygtKFUK7u3Z5qb/JdON; Authentication-Results: sj-dkim-7.cisco.com; header.From=jschnizl@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: geopriv@ietf.org, 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: , Errors-To: ecrit-bounces@ietf.org On Sep 11, 2006, at 4:36 AM, creed@opengeospatial.org wrote: > This conversation peaked my interest. I have just looked at RFC-3825. > Not > having been privy to all the original discussions and decisions, I am a > fresh set of "eyes" looking at this document. I think what we have > here is > a failure to communicate due to ambiguous semantics in 3825. I may be > wrong in this perception, but . . . > > Why you would claim not to have been in the discussions? On Jan 23, 2003, at 6:20 PM, Carl Reed wrote: > Hi Mark > > Very good questions and a proper concern. I will pass this question on > to a > real "datum professional". One of our members is the Chairman of the > EPSG > Geodesy group. We also have an entire Working Group dedicated to > Coordinate > Reference Systems (which include datums - horizontal and vertical). > > Regards > > Carl > > ----- Original Message ----- > From: Marc Linsner > To: Carl Reed > Cc: John Schnizlein ; James Polk > ; > > Sent: Thursday, January 23, 2003 8:16 AM > Subject: RE: I-D ACTION:draft-ietf-geopriv-dhcp-lo-option-00.txt > > >> Thank You! Those of us working on the draft certainly have been >> looking for a 'datum expert' to help us out! >> >> Now you're 'on the hook'! :^) >> >> If I'm correct in my intrepretation of the epsg database, it appears >> there >> are 267 datums. If we use the epsg codes, they require 2 bytes >> (actually 14 >> bits) to represent them in binary. You're implying that lining up >> with epsg >> is the proper thing to do, rather than creating news codes for each >> datum >> under the IANA umbrella. I'm struggling with the 'rumors on the >> street' >> that some of the datums may never be used - in fact only ~100 are >> actively >> used today. The part I'm struggling with is to utilize 2 bytes when >> only >> ~100 choices will be in use. >> >> Your thoughts one more time, please. >> >> -Marc Linsner- >> >> >> >>> -----Original Message----- >>> From: Carl Reed [mailto:creediii@mindspring.com] >>> Sent: Wednesday, January 22, 2003 6:15 PM >>> To: Marc Linsner >>> Subject: Re: I-D ACTION:draft-ietf-geopriv-dhcp-lo-option-00.txt >>> >>> >>> Hi Marc - >>> >>> There is no political issue related to a datum. There is no >>> "correct" datum for a locale. There can be many datums for a >>> given location - all of them correct. For example, in the US >>> many localgovernments deal with WGS 84, NAD 27, and NAD 83 datums. >>> Many local government planimetric databases are now in NAD 83. >>> In order for anyone to process a location and make sure that it >>> is georeferenced with a given planimetric or cadastral database, >>> the datum needs to be known. This is not a political issue - >>> simply a reality in the geospatial processing world >>> - especially one in which interoperability of >>> spatial data source (static and real time) is required. >>> >>> Regards >>> >>> Carl Reed _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 11 10:43:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMmzt-0004wA-6c; Mon, 11 Sep 2006 10:42:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMmzr-0004v4-NT; Mon, 11 Sep 2006 10:42:51 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMmzm-0006oj-HS; Mon, 11 Sep 2006 10:42:51 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Mon, 11 Sep 2006 10:42:38 -0400 id 015880CD.450575DE.00007BCA Message-ID: <450575DE.9090306@hxr.us> Date: Mon, 11 Sep 2006 10:42:38 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: John Schnizlein , creed@opengeospatial.org, geopriv@ietf.org Subject: Re: [Geopriv] RE: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy? References: <3b16f2ec895557379e48b424be6f0a12@cisco.com> <3086.218.208.53.35.1157963762.squirrel@mail.opengeospatial.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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: , Errors-To: ecrit-bounces@ietf.org John Schnizlein wrote: > > Why you would claim not to have been in the discussions? At this point, I will put my chair hat on and say that there is no need to go down this particular dark alley. So far, I am only hearing one person claiming that 3825 is inadequate and many other voices suggesting that it merely needs clarification. Certainly, 3825 would not be the first RFC in IETF history needing clarification. As part of any clarification effort, I think the community would be well served to have 3825 to GML conversion examples. Not having fully digested the requisite amount of morning coffee, I cannot easily judge if GML can express uncertainty about a point. That would "certainly" be helpful. And as Henning has suggested, we would also be well served by documented and agreed upon definitions of these terms. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 11 11:18:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMnYO-0005Dx-MR; Mon, 11 Sep 2006 11:18:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMnYM-0005CY-BO; Mon, 11 Sep 2006 11:18:30 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMnYK-0005fX-Ob; Mon, 11 Sep 2006 11:18:30 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Sep 2006 10:18:24 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Mon, 11 Sep 2006 10:18:23 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Sep 2006 10:18:23 -0500 Message-ID: From: "Winterbottom, James" To: "Andrew Newton" , "John Schnizlein" , , Date: Mon, 11 Sep 2006 10:18:20 -0500 Subject: RE: [Geopriv] RE: [Ecrit] Location information inemergency sessioninitiation, need for time and accuracy? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 11 Sep 2006 15:18:23.0058 (UTC) FILETIME=[85676320:01C6D5B5] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <450575DE.9090306@hxr.us> Content-class: urn:content-classes:message Thread-Topic: [Geopriv] RE: [Ecrit] Location information inemergency sessioninitiation, need for time and accuracy? Thread-Index: AcbVsMHtb2BkLU8qQ1WdU+eym0bNiwAAav6A X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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: , Errors-To: ecrit-bounces@ietf.org I am not sure that I know what Uncertainty about a point means. GML certainly can express areas of uncertainty and that was the purpose of the geoshapes draft. I might point out that the problems that Martin T and I have raised with regards to the encoding scheme in RFC-3825 have come about from exactly doing what is proposed below. We tried to turn the elements returned by RFC-3825 into a GML object. So to my mind I am not sure where this leaves us. Cheers James > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Tuesday, 12 September 2006 12:43 AM > To: John Schnizlein; creed@opengeospatial.org; geopriv@ietf.org > Cc: ecrit@ietf.org > Subject: Re: [Geopriv] RE: [Ecrit] Location information inemergency > sessioninitiation, need for time and accuracy? >=20 > John Schnizlein wrote: > > > > Why you would claim not to have been in the discussions? >=20 > At this point, I will put my chair hat on and say that there is no need to > go down this particular dark alley. >=20 > So far, I am only hearing one person claiming that 3825 is inadequate and > many other voices suggesting that it merely needs clarification. > Certainly, > 3825 would not be the first RFC in IETF history needing clarification. >=20 > As part of any clarification effort, I think the community would be well > served to have 3825 to GML conversion examples. Not having fully digested > the requisite amount of morning coffee, I cannot easily judge if GML can > express uncertainty about a point. That would "certainly" be helpful. >=20 > And as Henning has suggested, we would also be well served by documented > and > agreed upon definitions of these terms. >=20 > -andy >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 11 21:59:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMxY5-0002FI-GZ; Mon, 11 Sep 2006 21:58:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMxY4-0002FD-0D for ecrit@ietf.org; Mon, 11 Sep 2006 21:58:52 -0400 Received: from [86.59.12.252] (helo=sil1.mah.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMxY1-0002BJ-3V for ecrit@ietf.org; Mon, 11 Sep 2006 21:58:51 -0400 Received: from sil1.mah.priv.at ([86.59.12.250] helo=[127.0.0.1] ident=root) by sil1.mah.priv.at with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1GMxXk-00048t-V5; Tue, 12 Sep 2006 03:58:33 +0200 Message-ID: <45061430.8000602@mah.priv.at> Date: Tue, 12 Sep 2006 03:58:08 +0200 From: Michael Haberler User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Hannes Tschofenig References: <44FC6A4B.4080604@gmx.net> In-Reply-To: <44FC6A4B.4080604@gmx.net> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 86.59.12.250 X-SA-Exim-Mail-From: ml1234@mah.priv.at X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-26) on sil1.mah.priv.at X-Spam-Level: X-Spam-Status: No, score=-3.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.4 Subject: Re: [Ecrit] draft-ietf-ecrit-lost-01.txt - service area boundaries X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on sil1.mah.priv.at) X-Spam-Score: 0.5 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes - comment on "Figure 7: Response Message Example providing Civic Location Servic Boundary Hints": I think if a "service area" is returned, it should be possible to interpret it without further processing as an unambiguous geospatial object - assuming it should drive client behaviour (when do I need to re-fetch psap destination?) EXCEPT if the intent is usage solely for human consumption. if the former is the case, how do I interpret Bavaria Munich 81675 e.g as a polygon? I would assume that this could be the intersection of shapes of A1,A3 and PC. That would require to fetch shapes for A1, A3 and PC "somehow" and intersect them. Or just PC? that would imply "smallest shape counts"; again fetching the shape needed, how? Suggestion: always return geo polygons, and optionally return the civic name for use as a display name. -Michael _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 12 08:56:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN7oA-0006vM-6I; Tue, 12 Sep 2006 08:56:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN7o9-0006vH-ID for ecrit@ietf.org; Tue, 12 Sep 2006 08:56:09 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GN7o8-0000yX-88 for ecrit@ietf.org; Tue, 12 Sep 2006 08:56:09 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GN7o2-00008Z-UH; Tue, 12 Sep 2006 07:56:03 -0500 From: "Brian Rosen" To: "'Michael Haberler'" , "'Hannes Tschofenig'" Subject: RE: [Ecrit] draft-ietf-ecrit-lost-01.txt - service area boundaries Date: Tue, 12 Sep 2006 08:56:02 -0400 Message-ID: <098001c6d66a$cf44ae20$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcbWDxMavkQk5qMPTXO0c7Wxx2k+5QAW3EqA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <45061430.8000602@mah.priv.at> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I would want a return like > Bavaria > Munich > 81675 To mean that as long as I was in 81675, Munich, I could use the same URI. If I got out of that area, I should ask for a new mapping. I don't need a polygon for that. This is a very practical answer. If you get a civic address, I don't think returning a polygon is practical. Brian > -----Original Message----- > From: Michael Haberler [mailto:ml1234@mah.priv.at] > Sent: Monday, September 11, 2006 9:58 PM > To: Hannes Tschofenig > Cc: ECRIT > Subject: Re: [Ecrit] draft-ietf-ecrit-lost-01.txt - service area > boundaries > > Hannes - > > comment on "Figure 7: Response Message Example providing Civic Location > Servic Boundary Hints": > > I think if a "service area" is returned, it should be possible to > interpret it without further processing as an unambiguous geospatial > object - assuming it should drive client behaviour (when do I need to > re-fetch psap destination?) EXCEPT if the intent is usage solely for > human consumption. > > if the former is the case, how do I interpret > > Bavaria > Munich > 81675 > > e.g as a polygon? I would assume that this could be the intersection of > shapes of A1,A3 and PC. > > That would require to fetch shapes for A1, A3 and PC "somehow" and > intersect them. > Or just PC? that would imply "smallest shape counts"; again fetching the > shape needed, how? > > Suggestion: always return geo polygons, and optionally return the civic > name for use as a display name. > > -Michael > > > > > > > _______________________________________________ > 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 Sep 12 09:44:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN8Yk-0006vy-OR; Tue, 12 Sep 2006 09:44:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN8Yj-0006vo-Lo for ecrit@ietf.org; Tue, 12 Sep 2006 09:44:17 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GN8Ye-0000wP-Fy for ecrit@ietf.org; Tue, 12 Sep 2006 09:44:17 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Tue, 12 Sep 2006 09:43:51 -0400 id 015880FC.4506B998.00007767 Message-ID: <4506B99A.2070203@hxr.us> Date: Tue, 12 Sep 2006 09:43:54 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] draft-ietf-ecrit-lost-01.txt - service area boundaries References: <098001c6d66a$cf44ae20$640fa8c0@cis.neustar.com> In-Reply-To: <098001c6d66a$cf44ae20$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian Rosen wrote: > > This is a very practical answer. If you get a civic address, I don't think > returning a polygon is practical. Just to further the clarification, if a seeker submits a civic address in a query, they will get a civic address back as the service boundary. If a seeker submits a geodetic address, they will get a geodetic shape back as a service boundary. Perhaps the draft ought to be clearer on that point. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 13 18:10:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNcvP-000352-NX; Wed, 13 Sep 2006 18:09:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNcvO-00034x-8l for ecrit@ietf.org; Wed, 13 Sep 2006 18:09:42 -0400 Received: from [86.59.12.252] (helo=sil1.mah.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNcvM-0007Hs-Lm for ecrit@ietf.org; Wed, 13 Sep 2006 18:09:42 -0400 Received: from [64.251.112.98] (helo=[10.75.102.241]) by sil1.mah.priv.at with esmtpsa (SSL 3.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1GNcv8-0008E1-FN; Thu, 14 Sep 2006 00:09:27 +0200 Message-ID: <45088181.1060605@mah.priv.at> Date: Thu, 14 Sep 2006 00:09:05 +0200 From: Michael Haberler User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Brian Rosen , "Ecrit@Ietf.Org" References: <09a401c6d67d$ba4fb600$640fa8c0@cis.neustar.com> In-Reply-To: <09a401c6d67d$ba4fb600$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 64.251.112.98 X-SA-Exim-Mail-From: ml1234@mah.priv.at X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-26) on sil1.mah.priv.at X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.4 Subject: Re: [Ecrit] draft-ietf-ecrit-lost-01.txt - service area boundaries X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on sil1.mah.priv.at) X-Spam-Score: 0.5 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de 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: , Errors-To: ecrit-bounces@ietf.org Brian > with a civic, you likely would always get a civic. When you get the new > civic, you get a new postal code. If it changed, ask for a new mapping. you semi-answered my underlying question - how do you do out-of-service-area detection with civic address and civic area as returned from LoST as hint? can I interpret that as to mean: 1. the set of labels in the service area response is a proper subset of the set of labels in the device's current location 2. the label values of that subset all match as strings that algorithm would trigger as you decribed in setp 2 - is that what you're saying? -Michael > > > Now, if you started with a geo, and you got an update, it will be a geo. > Then you get a polygon. > > If you literally can roam through a public WiFi network, this likely will > actually happen. When they start doing triangulation between APs, you will > likely get a geo. > > Either way, the LoST mechanism as currently defined, should work well. > > Brian > > >> -----Original Message----- >> From: Michael Haberler [mailto:ml1234@mah.priv.at] >> Sent: Tuesday, September 12, 2006 9:52 AM >> To: Brian Rosen >> Subject: Re: [Ecrit] draft-ietf-ecrit-lost-01.txt - service area >> boundaries >> >> Brian Rosen schrieb: >> >>> I would want a return like >>> >>> >>>> Bavaria >>>> Munich >>>> 81675 >>>> >>>> >>> To mean that as long as I was in 81675, Munich, I could use the same >>> >> URI. >> >>> If I got out of that area, I should ask for a new mapping. I don't need >>> >> a >> >>> polygon for that. >>> >>> >> I believe *you* can distinguish "within 81675" from "outside 81675", >> many poor souls having suffered through Muenchen-Perlach can... >> >>> This is a very practical answer. If you get a civic address, I don't >>> >> think >> >>> returning a polygon is practical. >>> >>> >> How do you then, practically, teach your *device* to do the >> inside/outside discrimination based on the above data sample? >> >> The way I read the sample is - it's an area, not an address - hence >> polygon. It's there for a reason - so the device can do something with >> it - I just assumed it's more than saying on the screen "btw you are in >> Muenchen, postal code 81675" >> >> My understanding was that area descriptor hint is used to tell a device >> when it needs to re-query a LoST mapping - at least that's how I >> interpreted under features, section 1 of ecrit-lost-01: "Minimizes >> round trips by caching individual mappings and by supporting return of >> coverage regions ("hinting")." >> >> feeling LoST , >> >> -Michael >> >> btw could we rename this protocol to have a less hair-raising name? this >> sounds like a presales problem in the making. >> >> >>> Brian >>> >>> >>> >>>> -----Original Message----- >>>> From: Michael Haberler [mailto:ml1234@mah.priv.at] >>>> Sent: Monday, September 11, 2006 9:58 PM >>>> To: Hannes Tschofenig >>>> Cc: ECRIT >>>> Subject: Re: [Ecrit] draft-ietf-ecrit-lost-01.txt - service area >>>> boundaries >>>> >>>> Hannes - >>>> >>>> comment on "Figure 7: Response Message Example providing Civic Location >>>> Servic Boundary Hints": >>>> >>>> I think if a "service area" is returned, it should be possible to >>>> interpret it without further processing as an unambiguous geospatial >>>> object - assuming it should drive client behaviour (when do I need to >>>> re-fetch psap destination?) EXCEPT if the intent is usage solely for >>>> human consumption. >>>> >>>> if the former is the case, how do I interpret >>>> >>>> Bavaria >>>> Munich >>>> 81675 >>>> >>>> e.g as a polygon? I would assume that this could be the intersection of >>>> shapes of A1,A3 and PC. >>>> >>>> That would require to fetch shapes for A1, A3 and PC "somehow" and >>>> intersect them. >>>> Or just PC? that would imply "smallest shape counts"; again fetching >>>> >> the >> >>>> shape needed, how? >>>> >>>> Suggestion: always return geo polygons, and optionally return the civic >>>> name for use as a display name. >>>> >>>> -Michael >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 Sep 15 17:47:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOLWr-0006Sb-E9; Fri, 15 Sep 2006 17:47:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOLWq-0006Qo-5P for ecrit@ietf.org; Fri, 15 Sep 2006 17:47:20 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GOLWo-00053B-Nb for ecrit@ietf.org; Fri, 15 Sep 2006 17:47:20 -0400 Received: (qmail invoked by alias); 15 Sep 2006 21:47:17 -0000 Received: from dyn-160-39-243-197.dyn.columbia.edu (EHLO [160.39.243.197]) [160.39.243.197] by mail.gmx.net (mp010) with SMTP; 15 Sep 2006 23:47:17 +0200 X-Authenticated: #29516787 Message-ID: <450B1F68.10402@gmx.net> Date: Fri, 15 Sep 2006 17:47:20 -0400 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Leslie Daigle Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ECRIT Subject: [Ecrit] ECRIT (LoST) and draft-daigle-unaptr-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Leslie, the ECRIT working group is working on an XML-based protocol for mapping service identifiers and geospatial or civic location information to service contact URIs. You can find the document at: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-01.txt Based on your review of the Service URN draft http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-05.txt we have moved the DNS-based LoST discovery procedure to the LoST protocol draft. The described solution builds on your document http://www.ietf.org/internet-drafts/draft-daigle-unaptr-00.txt Here is the problem: We normatively depend on your document. The ECRIT milestones indicate that we need to finish the work on the mapping protocol by November 2006. Hence, we would like to ask you to accelerate your work on draft-daigle-unaptr-00.txt. When can you finish the document? If you cannot finish it very soon then we need to start thinking about a different solution. Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 18 08:06:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPHss-0007JO-0A; Mon, 18 Sep 2006 08:05:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GONFv-0002Bw-Dq for ecrit@ietf.org; Fri, 15 Sep 2006 19:37:59 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GONFu-0001H5-6f for ecrit@ietf.org; Fri, 15 Sep 2006 19:37:59 -0400 Received: from [192.168.0.109] ([::ffff:64.102.254.33]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Fri, 15 Sep 2006 19:37:41 -0400 id 01588423.450B3946.00006E32 Message-ID: <450B3944.6070507@thinkingcat.com> Date: Fri, 15 Sep 2006 19:37:40 -0400 From: Leslie Daigle User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Hannes Tschofenig References: <450B1F68.10402@gmx.net> In-Reply-To: <450B1F68.10402@gmx.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-Mailman-Approved-At: Mon, 18 Sep 2006 08:05:57 -0400 Cc: ECRIT Subject: [Ecrit] Re: ECRIT (LoST) and draft-daigle-unaptr-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Hannes, I don't think there would be a real problem for me to finish U-NAPTR in that timeframe (i.e., to the IESG by San Diego). I was primarily waiting for input (from various interested parties, not just the ECRIT WG) on the question of whether to write it as an update of S-NAPTR or a completely new DDDS application. I believe I have a reasonable fallback plan for how to handle that, if I get no further comments. Thanks, Leslie. Hannes Tschofenig wrote: > Hi Leslie, > > the ECRIT working group is working on an XML-based protocol for mapping > service identifiers and geospatial or civic location information to > service contact URIs. You can find the document at: > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-01.txt > > Based on your review of the Service URN draft > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-05.txt > we have moved the DNS-based LoST discovery procedure to the LoST > protocol draft. The described solution builds on your document > http://www.ietf.org/internet-drafts/draft-daigle-unaptr-00.txt > > Here is the problem: We normatively depend on your document. The ECRIT > milestones indicate that we need to finish the work on the mapping > protocol by November 2006. > > Hence, we would like to ask you to accelerate your work on > draft-daigle-unaptr-00.txt. When can you finish the document? > > If you cannot finish it very soon then we need to start thinking about a > different solution. > > Ciao > Hannes & Marc > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 18 16:37:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPPrr-0003HA-Be; Mon, 18 Sep 2006 16:37:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPPrp-0003Gk-QZ for ecrit@ietf.org; Mon, 18 Sep 2006 16:37:25 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPPro-00016Q-4O for ecrit@ietf.org; Mon, 18 Sep 2006 16:37:25 -0400 Received: from machine77.Level3.com (qfe0.f10212-07.adc1.oss.level3.com [10.2.1.102]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id k8IKbLvQ023527 for ; Mon, 18 Sep 2006 20:37:21 GMT Received: from machine77.Level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id 1151B124873 for ; Mon, 18 Sep 2006 20:37:21 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.9.12]) by scanner5.level3.com (Postfix) with SMTP id B8195124871 for ; Mon, 18 Sep 2006 20:37:20 +0000 (GMT) Received: from idc1exc0004.corp.global.level3.com ([10.1.9.15]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Sep 2006 14:37:20 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Sep 2006 14:37:19 -0600 Message-ID: <8EAEBD84136584449B84AC177199EC498D29E3@idc1exc0004.corp.global.level3.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Identifying 911 calls and avoid congestion for 911 calls Thread-Index: AcbbYjyTVmIUG+L7QaOai24tnr2gpQ== From: "Karihaloo, Ujjval" To: X-OriginalArrivalTime: 18 Sep 2006 20:37:20.0345 (UTC) FILETIME=[3D01E490:01C6DB62] X-Spam-Score: 0.1 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Subject: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls 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="===============0804127019==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0804127019== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6DB62.3CDC941E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6DB62.3CDC941E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 I had a question about how to identify 911 calls (via some specific SIP Header in the INVITE msg. any RFCs?) so that SIP Proxies that implement congestion do not drop 911 calls and treat them with highest priority when they reach their congestion threasholds. =20 Any pointers in this direction would help. =20 Thx, Ujjval. ------_=_NextPart_001_01C6DB62.3CDC941E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

   I had a question about how to identify = 911 calls (via some specific SIP Header in the INVITE msg. any RFCs?) so that SIP = Proxies that implement congestion do not drop 911 calls and treat them with highest = priority when they reach their congestion threasholds.

 

  Any pointers in this direction would = help.

 

Thx,

Ujjval.

------_=_NextPart_001_01C6DB62.3CDC941E-- --===============0804127019== 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 --===============0804127019==-- From ecrit-bounces@ietf.org Mon Sep 18 16:40:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPPur-0005Mk-Dr; Mon, 18 Sep 2006 16:40:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPPuq-0005Mf-DY for ecrit@ietf.org; Mon, 18 Sep 2006 16:40:32 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GPPuo-0002OO-W2 for ecrit@ietf.org; Mon, 18 Sep 2006 16:40:32 -0400 Received: (qmail invoked by alias); 18 Sep 2006 20:40:29 -0000 Received: from unknown (EHLO [192.168.1.66]) [66.54.228.162] by mail.gmx.net (mp005) with SMTP; 18 Sep 2006 22:40:29 +0200 X-Authenticated: #29516787 Message-ID: <450F0445.5050009@gmx.net> Date: Mon, 18 Sep 2006 16:40:37 -0400 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Karihaloo, Ujjval" Subject: Re: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls References: <8EAEBD84136584449B84AC177199EC498D29E3@idc1exc0004.corp.global.level3.com> In-Reply-To: <8EAEBD84136584449B84AC177199EC498D29E3@idc1exc0004.corp.global.level3.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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: , Errors-To: ecrit-bounces@ietf.org Here is the document: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-05.txt The document passed WGLC already. Ciao Hannes Karihaloo, Ujjval schrieb: > Hi All, > > > > I had a question about how to identify 911 calls (via some specific > SIP Header in the INVITE msg. any RFCs?) so that SIP Proxies that > implement congestion do not drop 911 calls and treat them with highest > priority when they reach their congestion threasholds. > > > > Any pointers in this direction would help. > > > > Thx, > > Ujjval. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 18 16:45:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPQ04-0003SX-Mc; Mon, 18 Sep 2006 16:45:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPQ03-0003S4-2f for ecrit@ietf.org; Mon, 18 Sep 2006 16:45:55 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPPzx-0005hp-Ai for ecrit@ietf.org; Mon, 18 Sep 2006 16:45:55 -0400 Received: from [66.54.228.162] (helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GPPyo-0006Gh-TZ; Mon, 18 Sep 2006 15:44:39 -0500 From: "Brian Rosen" To: "'Karihaloo, Ujjval'" , Subject: RE: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls Date: Mon, 18 Sep 2006 16:45:45 -0400 Message-ID: <00fd01c6db63$6beb3620$5401a8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <8EAEBD84136584449B84AC177199EC498D29E3@idc1exc0004.corp.global.level3.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbbYjyTVmIUG+L7QaOai24tnr2gpQAAQz5Q X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 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="===============1671216356==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1671216356== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00FE_01C6DB41.E4D99620" This is a multi-part message in MIME format. ------=_NextPart_000_00FE_01C6DB41.E4D99620 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit We have not yet decided how to do this. We need to. There are several related problems, because a call back from a PSAP to a caller should have the same characteristics. Brian _____ From: Karihaloo, Ujjval [mailto:Ujjval.Karihaloo@Level3.com] Sent: Monday, September 18, 2006 4:37 PM To: ecrit@ietf.org Subject: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls Hi All, I had a question about how to identify 911 calls (via some specific SIP Header in the INVITE msg. any RFCs?) so that SIP Proxies that implement congestion do not drop 911 calls and treat them with highest priority when they reach their congestion threasholds. Any pointers in this direction would help. Thx, Ujjval. ------=_NextPart_000_00FE_01C6DB41.E4D99620 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We have not yet decided how to do this.  We need to.  There are several related problems, = because a call back from a PSAP to a caller should have the same = characteristics.

 

Brian

 

From: = Karihaloo, Ujjval [mailto:Ujjval.Karihaloo@Level3.com]
Sent: Monday, September = 18, 2006 4:37 PM
To: ecrit@ietf.org
Subject: [Ecrit] = Identifying 911 calls and avoid congestion for 911 calls

 

Hi All,

 

   I had a question about how to identify = 911 calls (via some specific SIP Header in the INVITE msg. any RFCs?) so = that SIP Proxies that implement congestion do not drop 911 calls and treat them = with highest priority when they reach their congestion = threasholds.

 

  Any pointers in this direction would = help.

 

Thx,

Ujjval.

------=_NextPart_000_00FE_01C6DB41.E4D99620-- --===============1671216356== 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 --===============1671216356==-- From ecrit-bounces@ietf.org Mon Sep 18 16:47:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPQ1y-0005Pf-Cv; Mon, 18 Sep 2006 16:47:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPQ1x-0005KG-5A for ecrit@ietf.org; Mon, 18 Sep 2006 16:47:53 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPQ1k-0006Ue-Gs for ecrit@ietf.org; Mon, 18 Sep 2006 16:47:53 -0400 Received: from [66.54.228.162] (helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GPQ0b-0006O4-TC; Mon, 18 Sep 2006 15:46:30 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'Karihaloo, Ujjval'" Subject: RE: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls Date: Mon, 18 Sep 2006 16:47:36 -0400 Message-ID: <010201c6db63$ae122db0$5401a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <450F0445.5050009@gmx.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbbYofn76F1yMZRTmm+hlqUAw3alAAAOcCQ X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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: , Errors-To: ecrit-bounces@ietf.org This not the answer. The URN is dropped as soon as the mapping is completed. There was some discussion of putting a route header in with the URN which remained on the call all the way to the PSAP. That would not be sufficient, see my previous email. I think in the end we will create a namespace for the Resource Priority header for this purpose. Brian > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Monday, September 18, 2006 4:41 PM > To: Karihaloo, Ujjval > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Identifying 911 calls and avoid congestion for 911 > calls > > Here is the document: > > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-05.txt > > The document passed WGLC already. > > Ciao > Hannes > > Karihaloo, Ujjval schrieb: > > Hi All, > > > > > > > > I had a question about how to identify 911 calls (via some specific > > SIP Header in the INVITE msg. any RFCs?) so that SIP Proxies that > > implement congestion do not drop 911 calls and treat them with highest > > priority when they reach their congestion threasholds. > > > > > > > > Any pointers in this direction would help. > > > > > > > > Thx, > > > > Ujjval. > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 18 16:56:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPQ9h-0002Mc-4B; Mon, 18 Sep 2006 16:55:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPQ9f-0002MK-TM for ecrit@ietf.org; Mon, 18 Sep 2006 16:55:51 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPQ9d-0002ve-Mo for ecrit@ietf.org; Mon, 18 Sep 2006 16:55:51 -0400 Received: from [192.168.1.67] ([::ffff:66.54.228.162]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Mon, 18 Sep 2006 16:55:34 -0400 id 015880D4.450F07C6.00006C08 In-Reply-To: <010201c6db63$ae122db0$5401a8c0@cis.neustar.com> References: <010201c6db63$ae122db0$5401a8c0@cis.neustar.com> Mime-Version: 1.0 Message-Id: From: Andrew Newton Subject: Re: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls Date: Mon, 18 Sep 2006 16:55:43 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ecrit@ietf.org, "'Karihaloo, Ujjval'" 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="===============1601611116==" Errors-To: ecrit-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============1601611116== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-27660-1158612939-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-27660-1158612939-0001-2 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit On Sep 18, 2006, at 4:47 PM, Brian Rosen wrote: > This not the answer. The URN is dropped as soon as the mapping is > completed. When did we decide this? And why? -andy --=_zeke.ecotroph.net-27660-1158612939-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.53.3
On Sep 18, 2006, at 4:4= 7 PM, Brian Rosen wrote:

This not = the answer.=A0 The URN is dr= opped as soon as the mapping is

completed.


When did we = decide this?=A0 And why?

=
-andy
--=_zeke.ecotroph.net-27660-1158612939-0001-2-- --===============1601611116== 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 --===============1601611116==-- From ecrit-bounces@ietf.org Mon Sep 18 17:05:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPQJ9-0004QC-6m; Mon, 18 Sep 2006 17:05:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPQJ7-0004Pv-Ms for ecrit@ietf.org; Mon, 18 Sep 2006 17:05:37 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPQJ6-0003r5-9T for ecrit@ietf.org; Mon, 18 Sep 2006 17:05:37 -0400 Received: from [66.54.228.162] (helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GPQHx-0007Xh-40; Mon, 18 Sep 2006 16:04:25 -0500 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls Date: Mon, 18 Sep 2006 17:05:30 -0400 Message-ID: <012301c6db66$2f00da50$5401a8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbbZKurlZgNI0Q+SYCd5koYkhRRJQAALH5A X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 Cc: ecrit@ietf.org, "'Karihaloo, Ujjval'" 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="===============1787985743==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1787985743== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0124_01C6DB44.A7EF3A50" This is a multi-part message in MIME format. ------=_NextPart_000_0124_01C6DB44.A7EF3A50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Remembering that there was a suggestion to put the URN in the route rather than, or in addition to, the Request URI, it seems obvious that once you map, you are sending to the mapped URI and not the sos URN. Let's say that the originating device did not map. Then the To: field would (typically) be the dial string, and likely the initial Request URI. The element that does dialstring to URN mapping would substitute the URN for the dialstring. The element that does the mapping would substitute the PSAP URI for the URN in the Request URI. Of course, these steps could be combined. The result is still that the sos URN would be gone, unless, as I said, we put the sos URN in a Route header in addition to the Request URI. Brian _____ From: Andrew Newton [mailto:andy@hxr.us] Sent: Monday, September 18, 2006 4:56 PM To: Brian Rosen Cc: 'Hannes Tschofenig'; 'Karihaloo, Ujjval'; ecrit@ietf.org Subject: Re: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls On Sep 18, 2006, at 4:47 PM, Brian Rosen wrote: This not the answer. The URN is dropped as soon as the mapping is completed. When did we decide this? And why? -andy ------=_NextPart_000_0124_01C6DB44.A7EF3A50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Remembering that there was a = suggestion to put the URN in the route rather than, or in addition to, the Request = URI, it seems obvious that once you map, you are sending to the mapped URI and = not the sos URN. 

 

Let’s say that the = originating device did not map.  Then the To: field would (typically) be the = dial string, and likely the initial Request URI.  The element that does dialstring to URN mapping would substitute the URN for the = dialstring.  The element that does the mapping would substitute the PSAP URI for the = URN in the Request URI.  Of course, these steps could be combined.  = The result is still that the sos URN would be gone, unless, as I said, we = put the sos URN in a Route header in addition to the Request = URI.

 

Brian

 

From: = Andrew Newton [mailto:andy@hxr.us]
Sent: Monday, September = 18, 2006 4:56 PM
To: Brian Rosen
Cc: 'Hannes Tschofenig'; 'Karihaloo, Ujjval'; ecrit@ietf.org
Subject: Re: [Ecrit] = Identifying 911 calls and avoid congestion for 911 = calls

 

 

On Sep 18, 2006, at 4:47 PM, Brian Rosen = wrote:



This not the = answer. The URN is dropped as soon as the = mapping is

completed.<= o:p>

 

When did we decide this? And why?

 

-andy

------=_NextPart_000_0124_01C6DB44.A7EF3A50-- --===============1787985743== 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 --===============1787985743==-- From ecrit-bounces@ietf.org Mon Sep 18 17:31:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPQiA-0003Tt-NP; Mon, 18 Sep 2006 17:31:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPQi9-0003Sl-Vl for ecrit@ietf.org; Mon, 18 Sep 2006 17:31:29 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPQfu-00077e-Sx for ecrit@ietf.org; Mon, 18 Sep 2006 17:29:13 -0400 Received: from lion.cs.columbia.edu (IDENT:HXX8mrB0UDfpLnZw9JO9SXe6KogyOlQO@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k8ILT8Gb012824 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 18 Sep 2006 17:29:08 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k8ILT7g7021227 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 18 Sep 2006 17:29:08 -0400 Message-ID: <450F0F9E.2010101@cs.columbia.edu> Date: Mon, 18 Sep 2006 17:29:02 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls References: <012301c6db66$2f00da50$5401a8c0@cis.neustar.com> In-Reply-To: <012301c6db66$2f00da50$5401a8c0@cis.neustar.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter1.cs.columbia.edu Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by cs.columbia.edu id k8ILT8Gb012824 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: "'Karihaloo, Ujjval'" , 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: , Errors-To: ecrit-bounces@ietf.org The idea was slightly different: put the URN in the request URI and keep=20 it there, using the translated destination as (loose) Route headers.=20 (Obviously, if the URN was inserted into the To header, it stays there=20 as well.) Brian Rosen wrote: > Remembering that there was a suggestion to put the URN in the route=20 > rather than, or in addition to, the Request URI, it seems obvious that=20 > once you map, you are sending to the mapped URI and not the sos URN.=20 >=20 > =20 >=20 > Let=92s say that the originating device did not map. Then the To: fiel= d=20 > would (typically) be the dial string, and likely the initial Request=20 > URI. The element that does dialstring to URN mapping would substitute=20 > the URN for the dialstring. The element that does the mapping would=20 > substitute the PSAP URI for the URN in the Request URI. Of course,=20 > these steps could be combined. The result is still that the sos URN=20 > would be gone, unless, as I said, we put the sos URN in a Route header=20 > in addition to the Request URI. >=20 > =20 >=20 > Brian >=20 > =20 >=20 > -----------------------------------------------------------------------= - >=20 > *From:* Andrew Newton [mailto:andy@hxr.us] > *Sent:* Monday, September 18, 2006 4:56 PM > *To:* Brian Rosen > *Cc:* 'Hannes Tschofenig'; 'Karihaloo, Ujjval'; ecrit@ietf.org > *Subject:* Re: [Ecrit] Identifying 911 calls and avoid congestion for=20 > 911 calls >=20 > =20 >=20 > =20 >=20 > On Sep 18, 2006, at 4:47 PM, Brian Rosen wrote: >=20 >=20 >=20 > This not the answer. The URN is dropped as soon as the mapping is >=20 > completed. >=20 > =20 >=20 > When did we decide this? And why? >=20 > =20 >=20 > -andy >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 18 19:42:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPSkQ-0007aD-MK; Mon, 18 Sep 2006 19:41:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPSkP-0007Xt-BY for ecrit@ietf.org; Mon, 18 Sep 2006 19:41:57 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPSkL-000336-0I for ecrit@ietf.org; Mon, 18 Sep 2006 19:41:57 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 18 Sep 2006 16:41:52 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8INfqfS013562 for ; Mon, 18 Sep 2006 16:41:52 -0700 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 k8INfqYp025652 for ; Mon, 18 Sep 2006 16:41:52 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Sep 2006 16:41:51 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Sep 2006 16:41:51 -0700 From: "Marc Linsner" To: Date: Mon, 18 Sep 2006 19:41:48 -0400 Message-ID: <000001c6db7c$03db01f0$1152150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcbbZ8yDNqEfdYBnR8am9U6D/lORow== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-OriginalArrivalTime: 18 Sep 2006 23:41:51.0636 (UTC) FILETIME=[0402D540:01C6DB7C] DKIM-Signature: a=rsa-sha1; q=dns; l=463; t=1158622912; x=1159486912; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=22Marc=20Linsner=22=20 |Subject:Hum=20for=20draft-polk-ecrit-dhc-lost-discovery-00.txt; X=v=3Dcisco.com=3B=20h=3DZCiI8QL9dq8jdUz4zVMCi7UuDxs=3D; b=vBk6cJN+3zgMKSKsLAKY1bauoo7WmpzPKaKRlmB2eAkHyBBKbfRC2RP0xftA+1A4hTqGGm4p P/2tCdxrqS0DHuMuZKZB0+CrOvI/WE5Iu2Kv4SvQmV5HGPPebf4B5Q1H; Authentication-Results: sj-dkim-3.cisco.com; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Ecrit] Hum for draft-polk-ecrit-dhc-lost-discovery-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Please read this and express a hum for or against accepting as a wg item. I'll count hums at the end of this week. Title : A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service Translation Protocol (LoST) Discovery Procedure Author(s) : H. Schulzrinne, et al. Filename : draft-polk-ecrit-dhc-lost-discovery-00.txt Pages : 17 Date : 2006-9-5 Thanks, -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 18 21:23:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPUJs-0001n5-6V; Mon, 18 Sep 2006 21:22:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPUJr-0001n0-Fk for ecrit@ietf.org; Mon, 18 Sep 2006 21:22:39 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPUJp-0003cL-7M for ecrit@ietf.org; Mon, 18 Sep 2006 21:22:39 -0400 Received: from [10.0.0.103] ([::ffff:69.33.202.2]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Mon, 18 Sep 2006 21:21:58 -0400 id 015880D0.450F4636.000017AD In-Reply-To: <450F0F9E.2010101@cs.columbia.edu> References: <012301c6db66$2f00da50$5401a8c0@cis.neustar.com> <450F0F9E.2010101@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable Message-Id: From: Andrew Newton Subject: Re: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls Date: Mon, 18 Sep 2006 21:22:03 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: "'Karihaloo, Ujjval'" , 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: , Errors-To: ecrit-bounces@ietf.org Which draft is this in? -andy On Sep 18, 2006, at 5:29 PM, Henning Schulzrinne wrote: > The idea was slightly different: put the URN in the request URI and =20= > keep it there, using the translated destination as (loose) Route =20 > headers. (Obviously, if the URN was inserted into the To header, it =20= > stays there as well.) > > Brian Rosen wrote: >> Remembering that there was a suggestion to put the URN in the =20 >> route rather than, or in addition to, the Request URI, it seems =20 >> obvious that once you map, you are sending to the mapped URI and =20 >> not the sos URN. Let=92s say that the originating device did not =20 >> map. Then the To: field would (typically) be the dial string, and =20= >> likely the initial Request URI. The element that does dialstring =20 >> to URN mapping would substitute the URN for the dialstring. The =20 >> element that does the mapping would substitute the PSAP URI for =20 >> the URN in the Request URI. Of course, these steps could be =20 >> combined. The result is still that the sos URN would be gone, =20 >> unless, as I said, we put the sos URN in a Route header in =20 >> addition to the Request URI. >> Brian >> =20 >> ---------------------------------------------------------------------=20= >> --- >> *From:* Andrew Newton [mailto:andy@hxr.us] >> *Sent:* Monday, September 18, 2006 4:56 PM >> *To:* Brian Rosen >> *Cc:* 'Hannes Tschofenig'; 'Karihaloo, Ujjval'; ecrit@ietf.org >> *Subject:* Re: [Ecrit] Identifying 911 calls and avoid congestion =20 >> for 911 calls >> On Sep 18, 2006, at 4:47 PM, Brian Rosen wrote: >> This not the answer. The URN is dropped as soon as the mapping is >> completed. >> When did we decide this? And why? >> -andy >> ---------------------------------------------------------------------=20= >> --- >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 18 21:50:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPUkB-0005RA-PH; Mon, 18 Sep 2006 21:49:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPUk7-0005LL-Jf for ecrit@ietf.org; Mon, 18 Sep 2006 21:49:47 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPUcP-00070N-VY for ecrit@ietf.org; Mon, 18 Sep 2006 21:41:51 -0400 Received: from [192.168.0.41] (pool-141-153-175-20.mad.east.verizon.net [141.153.175.20]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k8J1fdGl026674 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 18 Sep 2006 21:41:40 -0400 (EDT) In-Reply-To: References: <012301c6db66$2f00da50$5401a8c0@cis.neustar.com> <450F0F9E.2010101@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Henning Schulzrinne Subject: Re: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls Date: Mon, 18 Sep 2006 21:41:29 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.2) X-PerlMx-Spam: Gauge=XXII, Probability=22%, X-Seen-By filter2.cs.columbia.edu 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: , Errors-To: ecrit-bounces@ietf.org I seem to recall that we agreed that this type of information should =20 be in the phone-bcp. I haven't checked whether it made it there. On Sep 18, 2006, at 9:22 PM, Andrew Newton wrote: > Which draft is this in? > > -andy > > > On Sep 18, 2006, at 5:29 PM, Henning Schulzrinne wrote: > >> The idea was slightly different: put the URN in the request URI =20 >> and keep it there, using the translated destination as (loose) =20 >> Route headers. (Obviously, if the URN was inserted into the To =20 >> header, it stays there as well.) >> >> Brian Rosen wrote: >>> Remembering that there was a suggestion to put the URN in the =20 >>> route rather than, or in addition to, the Request URI, it seems =20 >>> obvious that once you map, you are sending to the mapped URI and =20 >>> not the sos URN. Let=92s say that the originating device did not =20= >>> map. Then the To: field would (typically) be the dial string, =20 >>> and likely the initial Request URI. The element that does =20 >>> dialstring to URN mapping would substitute the URN for the =20 >>> dialstring. The element that does the mapping would substitute =20 >>> the PSAP URI for the URN in the Request URI. Of course, these =20 >>> steps could be combined. The result is still that the sos URN =20 >>> would be gone, unless, as I said, we put the sos URN in a Route =20 >>> header in addition to the Request URI. >>> Brian >>> =20 >>> --------------------------------------------------------------------=20= >>> ---- >>> *From:* Andrew Newton [mailto:andy@hxr.us] >>> *Sent:* Monday, September 18, 2006 4:56 PM >>> *To:* Brian Rosen >>> *Cc:* 'Hannes Tschofenig'; 'Karihaloo, Ujjval'; ecrit@ietf.org >>> *Subject:* Re: [Ecrit] Identifying 911 calls and avoid congestion =20= >>> for 911 calls >>> On Sep 18, 2006, at 4:47 PM, Brian Rosen wrote: >>> This not the answer. The URN is dropped as soon as the mapping is >>> completed. >>> When did we decide this? And why? >>> -andy >>> --------------------------------------------------------------------=20= >>> ---- >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 19 06:03:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPcRA-0005Gr-Dn; Tue, 19 Sep 2006 06:02:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPcR9-0005Fb-BV for ecrit@ietf.org; Tue, 19 Sep 2006 06:02:43 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPcR7-0002g3-SJ for ecrit@ietf.org; Tue, 19 Sep 2006 06:02:43 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k8JA2eZA027520 for ; Tue, 19 Sep 2006 13:02:40 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Sep 2006 13:02:40 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Sep 2006 13:02:40 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Sep 2006 13:02:38 +0300 Message-ID: <29685ED45627A84ABE58DDFC37CC3B2303529382@trebe101.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multiple sources of location information and timestamp Thread-Index: Acbb0ryxQ+6+LKLaRI24QqbFaqG12A== From: To: X-OriginalArrivalTime: 19 Sep 2006 10:02:40.0429 (UTC) FILETIME=[BE0595D0:01C6DBD2] X-Spam-Score: 0.3 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [Ecrit] Multiple sources of location information and timestamp 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="===============0562102850==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0562102850== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6DBD2.BDE3C20A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6DBD2.BDE3C20A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, UE may include multiple location objects into emergency session INVITE. To my knowledge it has not been defined how to select which one of the location objects is used for routing to PSAP if the location objects lead to different PSAPs. I think timestamp when the location objects were created could be useful in selecting the most recent location information but PIDF defines timestamp only for the whole presence tuple. Has this been discussed and does anybody see this as a problmem? Or is there some way to identify the time when the location object was created? Br, Vesa Hakkarainen ------_=_NextPart_001_01C6DBD2.BDE3C20A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Multiple sources of location information and timestamp

Hi all,

UE may include multiple location = objects into emergency session INVITE. To my knowledge it has not been = defined how to select which one of the location objects is used for = routing to PSAP if the location objects lead to different PSAPs. I think = timestamp when the location objects were created could be useful in = selecting the most recent location information but PIDF defines = timestamp only for the whole presence tuple. Has this been discussed and = does anybody see this as a problmem? Or is there some way to identify = the time when the location object was created?

Br,
        Vesa Hakkarainen

------_=_NextPart_001_01C6DBD2.BDE3C20A-- --===============0562102850== 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 --===============0562102850==-- From ecrit-bounces@ietf.org Tue Sep 19 06:50:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPdBU-0006iJ-9P; Tue, 19 Sep 2006 06:50:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPdBT-0006h5-98 for ecrit@ietf.org; Tue, 19 Sep 2006 06:50:35 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPdBR-0005ww-0A for ecrit@ietf.org; Tue, 19 Sep 2006 06:50:35 -0400 Received: from [10.0.0.103] ([::ffff:69.33.202.2]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Tue, 19 Sep 2006 06:50:12 -0400 id 015880F0.450FCB64.000013F6 In-Reply-To: <29685ED45627A84ABE58DDFC37CC3B2303529382@trebe101.NOE.Nokia.com> References: <29685ED45627A84ABE58DDFC37CC3B2303529382@trebe101.NOE.Nokia.com> Mime-Version: 1.0 Message-Id: From: Andrew Newton Subject: Re: [Ecrit] Multiple sources of location information and timestamp Date: Tue, 19 Sep 2006 06:50:20 -0400 To: vesa-matti.hakkarainen@nokia.com X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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: , Content-Type: multipart/mixed; boundary="===============0088650156==" Errors-To: ecrit-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============0088650156== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-5112-1158663022-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-5112-1158663022-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Sep 19, 2006, at 6:02 AM, vesa-matti.hakkarainen@nokia.com wrote: > Hi all, > > UE may include multiple location objects into emergency session > INVITE. To my knowledge it has not been defined how to select which > one of the location objects is used for routing to PSAP if the > location objects lead to different PSAPs. I think timestamp when > the location objects were created could be useful in selecting the > most recent location information but PIDF defines timestamp only > for the whole presence tuple. Has this been discussed and does > anybody see this as a problmem? Or is there some way to identify > the time when the location object was created? > > Br, > Vesa Hakkarainen We've been round and round on the discussion about what to feed the routing function (LoST). Until now, we have assumed it is the location being conveyed to the PSAP. But there seems to be a problem. If the input to the routing function is complex, the results are undesirable. Yet, there seems to be a desire to have the PSAPs get these very complex shapes. Perhaps there should be two sets of location info, each clearly marked: one for routing, one for the PSAPs. I'd also suggest giving the PSAPs the input to the routing function as well, but clearly marking the purpose of the information could help solve this problem. -andy --=_zeke.ecotroph.net-5112-1158663022-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.53.3
On Sep 19, 2006, at 6:0= 2 AM, vesa-matti.hakk= arainen@nokia.com wrote:

Hi all,

UE may include multiple locati= on objects into emergency session INVITE. To my knowledge it has not been= defined how to select which one of the location objects is used for rout= ing to PSAP if the location objects lead to different PSAPs. I think time= stamp when the location objects were created could be useful in selecting= the most recent location information but PIDF defines timestamp only for= the whole presence tuple. Has this been discussed and does anybody see t= his as a problmem? Or is there some way to identify the time when the loc= ation object was created?

Br= ,
=A0=A0=A0=A0=A0=A0=A0 Vesa H= akkarainen


We've been round and ro= und on the discussion about what to feed the routing function (LoST).=A0 = Until now, we have assumed it is the location being conveyed to the PSAP.= =A0 But there seems to be a problem.=A0 If the input to the routing funct= ion is complex, the results are undesirable.=A0 Yet, there seems to be a = desire to have the PSAPs get these very complex shapes.

Perhaps there should be two set= s of location info, each clearly marked: one for routing, one for the PSA= Ps.=A0 I'd also suggest giving the PSAPs the input to the routing functio= n as well, but clearly marking the purpose of the information could help = solve this problem.

-andy
--=_zeke.ecotroph.net-5112-1158663022-0001-2-- --===============0088650156== 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 --===============0088650156==-- From ecrit-bounces@ietf.org Tue Sep 19 09:10:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPfMd-0004CC-O9; Tue, 19 Sep 2006 09:10:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPfMc-0004C7-OH for ecrit@ietf.org; Tue, 19 Sep 2006 09:10:14 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPfMa-0004LG-Bg for ecrit@ietf.org; Tue, 19 Sep 2006 09:10:14 -0400 Received: from [66.54.228.162] (helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GPfLE-00007D-WA; Tue, 19 Sep 2006 08:08:49 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Andrew Newton'" Subject: RE: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls Date: Tue, 19 Sep 2006 09:10:02 -0400 Message-ID: <00ce01c6dbec$ecbea640$7647540a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcbbjJsP1Iz8veB9Roiqd1g58XcOMgAX6kaw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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: , Errors-To: ecrit-bounces@ietf.org Having thought through this, I think it's a lousy idea. The reason is that EVERY element between the endpoint and the PSAP must be upgraded to have new behavior = recognize the service URN, "ignore" it, and route based on the route header. It really violates the spirit of 3261 where you can safely ignore things you don't understand, recognizing that proxies have to be able to deal with the URN in the Request URI for as long as it's there. I think a Resource Priority header would have the right characteristics. It could also serve for a call back placed by a PSAP towards an endpoint. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, September 18, 2006 9:41 PM > To: Andrew Newton > Cc: Brian Rosen; Ecrit@Ietf.Org > Subject: Re: [Ecrit] Identifying 911 calls and avoid congestion for 911 > calls > > I seem to recall that we agreed that this type of information should > be in the phone-bcp. I haven't checked whether it made it there. > > On Sep 18, 2006, at 9:22 PM, Andrew Newton wrote: > > > Which draft is this in? > > > > -andy > > > > > > On Sep 18, 2006, at 5:29 PM, Henning Schulzrinne wrote: > > > >> The idea was slightly different: put the URN in the request URI > >> and keep it there, using the translated destination as (loose) > >> Route headers. (Obviously, if the URN was inserted into the To > >> header, it stays there as well.) > >> > >> Brian Rosen wrote: > >>> Remembering that there was a suggestion to put the URN in the > >>> route rather than, or in addition to, the Request URI, it seems > >>> obvious that once you map, you are sending to the mapped URI and > >>> not the sos URN. Let's say that the originating device did not > >>> map. Then the To: field would (typically) be the dial string, > >>> and likely the initial Request URI. The element that does > >>> dialstring to URN mapping would substitute the URN for the > >>> dialstring. The element that does the mapping would substitute > >>> the PSAP URI for the URN in the Request URI. Of course, these > >>> steps could be combined. The result is still that the sos URN > >>> would be gone, unless, as I said, we put the sos URN in a Route > >>> header in addition to the Request URI. > >>> Brian > >>> > >>> -------------------------------------------------------------------- > >>> ---- > >>> *From:* Andrew Newton [mailto:andy@hxr.us] > >>> *Sent:* Monday, September 18, 2006 4:56 PM > >>> *To:* Brian Rosen > >>> *Cc:* 'Hannes Tschofenig'; 'Karihaloo, Ujjval'; ecrit@ietf.org > >>> *Subject:* Re: [Ecrit] Identifying 911 calls and avoid congestion > >>> for 911 calls > >>> On Sep 18, 2006, at 4:47 PM, Brian Rosen wrote: > >>> This not the answer. The URN is dropped as soon as the mapping is > >>> completed. > >>> When did we decide this? And why? > >>> -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 Sep 19 09:27:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPfd9-0001k2-1I; Tue, 19 Sep 2006 09:27:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPfd7-0001ff-QD for ecrit@ietf.org; Tue, 19 Sep 2006 09:27:17 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPfd6-0002jx-Hy for ecrit@ietf.org; Tue, 19 Sep 2006 09:27:17 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.6/IER-o) with ESMTP id k8JDR0HT027779; Tue, 19 Sep 2006 08:27:00 -0500 (CDT) Received: from jrrosenberg-04.lucent.com (jrrosenberg-04.ih.lucent.com [135.185.233.167]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k8JDR0A27115; Tue, 19 Sep 2006 08:27:00 -0500 (CDT) Message-Id: <6.2.1.2.0.20060919081753.034c0028@ihmail.ih.lucent.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 19 Sep 2006 08:26:58 -0500 To: "Brian Rosen" , "'Henning Schulzrinne'" , "'Andrew Newton'" From: John Rosenberg Subject: RE: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls In-Reply-To: <00ce01c6dbec$ecbea640$7647540a@cis.neustar.com> References: <00ce01c6dbec$ecbea640$7647540a@cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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: , Errors-To: ecrit-bounces@ietf.org Using Resource-Priority is and interesting suggestion. RPH does have an element of call-type identification based on the namespace value. However, RPH's main goal is to communicate a priority level to be used in conjunction with resource allocation, especially during congestion or in the face of resource contention - not quite what we're doing here. I know that at least one service provider is suggesting the use of a mode=emergency tag in the R-URI. John Rosenberg At 08:10 AM 9/19/2006, Brian Rosen wrote: >Having thought through this, I think it's a lousy idea. > >The reason is that EVERY element between the endpoint and the PSAP must be >upgraded to have new behavior = recognize the service URN, "ignore" it, and >route based on the route header. It really violates the spirit of 3261 >where you can safely ignore things you don't understand, recognizing that >proxies have to be able to deal with the URN in the Request URI for as long >as it's there. > >I think a Resource Priority header would have the right characteristics. It >could also serve for a call back placed by a PSAP towards an endpoint. > >Brian > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 19 09:58:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPg6r-000515-Kf; Tue, 19 Sep 2006 09:58:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPg6q-0004xM-6j for ecrit@ietf.org; Tue, 19 Sep 2006 09:58:00 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPftF-00085x-6W for ecrit@ietf.org; Tue, 19 Sep 2006 09:43:58 -0400 Received: from [66.54.228.162] (helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GPfry-0003RI-PF; Tue, 19 Sep 2006 08:42:39 -0500 From: "Brian Rosen" To: "'John Rosenberg'" , "'Henning Schulzrinne'" , "'Andrew Newton'" Subject: RE: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls Date: Tue, 19 Sep 2006 09:43:52 -0400 Message-ID: <00d901c6dbf1$a6ba8240$7647540a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acbb7xv+kDaCh1V9Q0KyeLrwY9JMEAAAbn/g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <6.2.1.2.0.20060919081753.034c0028@ihmail.ih.lucent.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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: , Errors-To: ecrit-bounces@ietf.org That is precisely the behavior we want. The only reason most elements need to know that a particular call is an emergency call is to give it priority on resource allocation. It MAY also be used in some "unitialized device" circumstances where otherwise the call would not be allowed at all. That service provider should make the proposal here, as this is where such behavior would be decided I think. Brian > -----Original Message----- > From: John Rosenberg [mailto:jrrosenberg@lucent.com] > Sent: Tuesday, September 19, 2006 9:27 AM > To: Brian Rosen; 'Henning Schulzrinne'; 'Andrew Newton' > Cc: 'Ecrit@Ietf.Org' > Subject: RE: [Ecrit] Identifying 911 calls and avoid congestion for 911 > calls > > Using Resource-Priority is and interesting suggestion. RPH does have an > element of call-type identification based on the namespace value. However, > RPH's main goal is to communicate a priority level to be used in > conjunction with resource allocation, especially during congestion or in > the face of resource contention - not quite what we're doing here. > > I know that at least one service provider is suggesting the use of a > mode=emergency tag in the R-URI. > > John Rosenberg > > > > > At 08:10 AM 9/19/2006, Brian Rosen wrote: > >Having thought through this, I think it's a lousy idea. > > > >The reason is that EVERY element between the endpoint and the PSAP must > be > >upgraded to have new behavior = recognize the service URN, "ignore" it, > and > >route based on the route header. It really violates the spirit of 3261 > >where you can safely ignore things you don't understand, recognizing > that > >proxies have to be able to deal with the URN in the Request URI for as > long > >as it's there. > > > >I think a Resource Priority header would have the right characteristics. > It > >could also serve for a call back placed by a PSAP towards an endpoint. > > > >Brian > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 19 10:58:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPh3U-0003Bk-4I; Tue, 19 Sep 2006 10:58:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPh3S-0003AE-R9 for ecrit@ietf.org; Tue, 19 Sep 2006 10:58:34 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPh3R-0005Zg-Jl for ecrit@ietf.org; Tue, 19 Sep 2006 10:58:34 -0400 Received: from lion.cs.columbia.edu (IDENT:J7mIVmIyykEt+40GBJusjJ+a4UyQeqwL@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k8JEwUGb004154 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 19 Sep 2006 10:58:30 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k8JEwTg7023442 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 19 Sep 2006 10:58:30 -0400 Message-ID: <45100591.6040609@cs.columbia.edu> Date: Tue, 19 Sep 2006 10:58:25 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: John Rosenberg Subject: Re: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls References: <00ce01c6dbec$ecbea640$7647540a@cis.neustar.com> <6.2.1.2.0.20060919081753.034c0028@ihmail.ih.lucent.com> In-Reply-To: <6.2.1.2.0.20060919081753.034c0028@ihmail.ih.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter2.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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: , Errors-To: ecrit-bounces@ietf.org I think we should distinguish several aspects, i.e., what's the purpose of marking? - indicate routing requests (applies to any service URN, not just emergency); in particular, whether a new, more specific, next hop needs to be computed - indicate priority handling (applies only to emergency, but maybe not test calls) The Route/Request-URI behavior I suggested is standard SIP RFC 3261 behavior, not anything new. John Rosenberg wrote: > Using Resource-Priority is and interesting suggestion. RPH does have an > element of call-type identification based on the namespace value. > However, RPH's main goal is to communicate a priority level to be used > in conjunction with resource allocation, especially during congestion or > in the face of resource contention - not quite what we're doing here. > > I know that at least one service provider is suggesting the use of a > mode=emergency tag in the R-URI. > > John Rosenberg > > > > > At 08:10 AM 9/19/2006, Brian Rosen wrote: > >Having thought through this, I think it's a lousy idea. > > > >The reason is that EVERY element between the endpoint and the PSAP > must be > >upgraded to have new behavior = recognize the service URN, "ignore" > it, and > >route based on the route header. It really violates the spirit of 3261 > >where you can safely ignore things you don't understand, recognizing that > >proxies have to be able to deal with the URN in the Request URI for as > long > >as it's there. > > > >I think a Resource Priority header would have the right > characteristics. It > >could also serve for a call back placed by a PSAP towards an endpoint. > > > >Brian > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 19 11:54:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPhvG-0002QY-La; Tue, 19 Sep 2006 11:54:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPhvF-0002Op-3c for ecrit@ietf.org; Tue, 19 Sep 2006 11:54:09 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPhvC-0004Vi-OR for ecrit@ietf.org; Tue, 19 Sep 2006 11:54:09 -0400 Received: from [66.54.228.162] (helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GPhtv-0004Wq-2t; Tue, 19 Sep 2006 10:52:47 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'John Rosenberg'" Subject: RE: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls Date: Tue, 19 Sep 2006 11:54:02 -0400 Message-ID: <010001c6dc03$d57adf50$7647540a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acbb++Tjzkai6JIXQpq9zETBVfmLqgAB4bCg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <45100591.6040609@cs.columbia.edu> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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: , Errors-To: ecrit-bounces@ietf.org If you leave the service URN in the Request URI, how do you know whether any LoST mapping has been performed? That is, how do you know whether a new, more specific next hop needs to be computed? Presence of a Route header doesn't seem to be a good indication. I do agree on your separation of marking aspects. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, September 19, 2006 10:58 AM > To: John Rosenberg > Cc: Brian Rosen; 'Andrew Newton'; 'Ecrit@Ietf.Org' > Subject: Re: [Ecrit] Identifying 911 calls and avoid congestion for 911 > calls > > I think we should distinguish several aspects, i.e., what's the purpose > of marking? > > - indicate routing requests (applies to any service URN, not just > emergency); in particular, whether a new, more specific, next hop needs > to be computed > > - indicate priority handling (applies only to emergency, but maybe not > test calls) > > The Route/Request-URI behavior I suggested is standard SIP RFC 3261 > behavior, not anything new. > > John Rosenberg wrote: > > Using Resource-Priority is and interesting suggestion. RPH does have an > > element of call-type identification based on the namespace value. > > However, RPH's main goal is to communicate a priority level to be used > > in conjunction with resource allocation, especially during congestion or > > in the face of resource contention - not quite what we're doing here. > > > > I know that at least one service provider is suggesting the use of a > > mode=emergency tag in the R-URI. > > > > John Rosenberg > > > > > > > > > > At 08:10 AM 9/19/2006, Brian Rosen wrote: > > >Having thought through this, I think it's a lousy idea. > > > > > >The reason is that EVERY element between the endpoint and the PSAP > > must be > > >upgraded to have new behavior = recognize the service URN, "ignore" > > it, and > > >route based on the route header. It really violates the spirit of > 3261 > > >where you can safely ignore things you don't understand, recognizing > that > > >proxies have to be able to deal with the URN in the Request URI for as > > long > > >as it's there. > > > > > >I think a Resource Priority header would have the right > > characteristics. It > > >could also serve for a call back placed by a PSAP towards an endpoint. > > > > > >Brian > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 19 11:55:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPhwi-0003A8-22; Tue, 19 Sep 2006 11:55:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPhwh-00039y-HF for ecrit@ietf.org; Tue, 19 Sep 2006 11:55:39 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GPhwg-0004c2-3z for ecrit@ietf.org; Tue, 19 Sep 2006 11:55:39 -0400 Received: (qmail invoked by alias); 19 Sep 2006 15:55:36 -0000 Received: from unknown (EHLO [192.168.1.66]) [66.54.228.162] by mail.gmx.net (mp003) with SMTP; 19 Sep 2006 17:55:36 +0200 X-Authenticated: #29516787 Message-ID: <451012FE.9090109@gmx.net> Date: Tue, 19 Sep 2006 11:55:42 -0400 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Marc Linsner Subject: Re: [Ecrit] Hum for draft-polk-ecrit-dhc-lost-discovery-00.txt References: <000001c6db7c$03db01f0$1152150a@amer.cisco.com> In-Reply-To: <000001c6db7c$03db01f0$1152150a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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: , Errors-To: ecrit-bounces@ietf.org Please respond since we want to finish the LoST as soon as possible. Comments on the LoST draft are also very much appreciated. Marc Linsner schrieb: > Please read this and express a hum for or against accepting as a wg item. > I'll count hums at the end of this week. > > > Title : A Dynamic Host Configuration Protocol (DHCP) > based Location-to-Service Translation > Protocol (LoST) Discovery Procedure > Author(s) : H. Schulzrinne, et al. > Filename : draft-polk-ecrit-dhc-lost-discovery-00.txt > Pages : 17 > Date : 2006-9-5 > > > Thanks, > > -Marc- > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 19 13:37:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPjXC-0004h2-KQ; Tue, 19 Sep 2006 13:37:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPjXB-0004gx-7F for ecrit@ietf.org; Tue, 19 Sep 2006 13:37:25 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPjXA-0003xE-1e for ecrit@ietf.org; Tue, 19 Sep 2006 13:37:25 -0400 Received: from [192.168.1.67] ([::ffff:66.54.228.162]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Tue, 19 Sep 2006 13:37:04 -0400 id 0158805C.45102AC0.00006A15 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <000001c6db7c$03db01f0$1152150a@amer.cisco.com> References: <000001c6db7c$03db01f0$1152150a@amer.cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Hum for draft-polk-ecrit-dhc-lost-discovery-00.txt Date: Tue, 19 Sep 2006 13:37:12 -0400 To: "Ecrit@Ietf.Org" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.5 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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: , Errors-To: ecrit-bounces@ietf.org I don't understand why the draft describes three different ways of doing this: ip addresses, a records, and naptr records... the latter seemingly missing the point of naptr records. This draft should simply provide one thing: a domain name. That would be the input into the U-NAPTR algorithm along with the service URN. From there, multiple naptrs can be found, pointing to URIs. And pointing to a URIs is essential, as the HTTP request path cannot be gleened via just an IP address or A record. I'd like to see this fixed before the working group adopts this item. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 19 13:40:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPja6-0008NS-8e; Tue, 19 Sep 2006 13:40:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPja4-0008Kr-R5 for ecrit@ietf.org; Tue, 19 Sep 2006 13:40:24 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GPja3-0004Od-D8 for ecrit@ietf.org; Tue, 19 Sep 2006 13:40:24 -0400 Received: (qmail invoked by alias); 19 Sep 2006 17:40:22 -0000 Received: from unknown (EHLO [192.168.1.66]) [66.54.228.162] by mail.gmx.net (mp018) with SMTP; 19 Sep 2006 19:40:22 +0200 X-Authenticated: #29516787 Message-ID: <45102B8C.5080803@gmx.net> Date: Tue, 19 Sep 2006 13:40:28 -0400 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] Hum for draft-polk-ecrit-dhc-lost-discovery-00.txt References: <000001c6db7c$03db01f0$1152150a@amer.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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: , Errors-To: ecrit-bounces@ietf.org Hi Andy, we used the SIP-based discovery work. Hence, it was fine with SIP proxy server discovery why isn't it fine todo the same here as well? Ciao Hannes Andrew Newton schrieb: > I don't understand why the draft describes three different ways of doing > this: ip addresses, a records, and naptr records... the latter seemingly > missing the point of naptr records. > > This draft should simply provide one thing: a domain name. That would > be the input into the U-NAPTR algorithm along with the service URN. > From there, multiple naptrs can be found, pointing to URIs. And > pointing to a URIs is essential, as the HTTP request path cannot be > gleened via just an IP address or A record. > > I'd like to see this fixed before the working group adopts this item. > > -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 Sep 19 13:47:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPjgj-0005vD-8e; Tue, 19 Sep 2006 13:47:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPjgg-0005uy-JK for ecrit@ietf.org; Tue, 19 Sep 2006 13:47:14 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPjge-0005z3-DR for ecrit@ietf.org; Tue, 19 Sep 2006 13:47:14 -0400 Received: from [192.168.1.67] ([::ffff:66.54.228.162]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Tue, 19 Sep 2006 13:46:58 -0400 id 015880FA.45102D12.00006BFA In-Reply-To: <45102B8C.5080803@gmx.net> References: <000001c6db7c$03db01f0$1152150a@amer.cisco.com> <45102B8C.5080803@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1A46B9C2-7AAC-4CED-B7EE-722DA9100986@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Hum for draft-polk-ecrit-dhc-lost-discovery-00.txt Date: Tue, 19 Sep 2006 13:47:07 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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: , Errors-To: ecrit-bounces@ietf.org On Sep 19, 2006, at 1:40 PM, Hannes Tschofenig wrote: > > we used the SIP-based discovery work. I don't understand this. > Hence, it was fine with SIP proxy server discovery why isn't it > fine todo the same here as well? Perhaps because this is a configuration mechanism, which might be used in one of the steps for discovery. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 19 13:48:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPjhR-0006HB-Tl; Tue, 19 Sep 2006 13:48:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPjhQ-0006H6-3e for ecrit@ietf.org; Tue, 19 Sep 2006 13:48:00 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GPjhO-00068s-Mb for ecrit@ietf.org; Tue, 19 Sep 2006 13:48:00 -0400 Received: (qmail invoked by alias); 19 Sep 2006 17:47:57 -0000 Received: from unknown (EHLO [192.168.1.66]) [66.54.228.162] by mail.gmx.net (mp001) with SMTP; 19 Sep 2006 19:47:57 +0200 X-Authenticated: #29516787 Message-ID: <45102D53.5020205@gmx.net> Date: Tue, 19 Sep 2006 13:48:03 -0400 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] Hum for draft-polk-ecrit-dhc-lost-discovery-00.txt References: <000001c6db7c$03db01f0$1152150a@amer.cisco.com> <45102B8C.5080803@gmx.net> In-Reply-To: <45102B8C.5080803@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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: , Errors-To: ecrit-bounces@ietf.org Let me be a bit more precise: We used the procedure used in RFC 3361 and from RFC 3319. RFC 3361 Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers RFC 3319 Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers Ciao Hannes Hannes Tschofenig schrieb: > Hi Andy, > > we used the SIP-based discovery work. Hence, it was fine with SIP proxy > server discovery why isn't it fine todo the same here as well? > > Ciao > Hannes > > Andrew Newton schrieb: >> I don't understand why the draft describes three different ways of >> doing this: ip addresses, a records, and naptr records... the latter >> seemingly missing the point of naptr records. >> >> This draft should simply provide one thing: a domain name. That would >> be the input into the U-NAPTR algorithm along with the service URN. >> From there, multiple naptrs can be found, pointing to URIs. And >> pointing to a URIs is essential, as the HTTP request path cannot be >> gleened via just an IP address or A record. >> >> I'd like to see this fixed before the working group adopts this item. >> >> -andy >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> >> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 19 21:47:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPrAs-00011M-6I; Tue, 19 Sep 2006 21:46:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPrAr-0000yo-Em for ecrit@ietf.org; Tue, 19 Sep 2006 21:46:53 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPrAq-0007K1-2c for ecrit@ietf.org; Tue, 19 Sep 2006 21:46:53 -0400 Received: from [192.168.0.101] (S010600095b9792b5.vc.shawcable.net [24.85.243.115]) (authenticated) by agnada.com (8.11.6/8.11.6) with ESMTP id k8JKRGv00567; Tue, 19 Sep 2006 14:27:16 -0600 Message-ID: <451052A5.4070307@ntt-at.com> Date: Tue, 19 Sep 2006 13:27:17 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls References: <010001c6dc03$d57adf50$7647540a@cis.neustar.com> In-Reply-To: <010001c6dc03$d57adf50$7647540a@cis.neustar.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: "'Ecrit@Ietf.Org'" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org AFAIK as we allow usage of cached PSAP URI or even PSAP URI that was given by some non LoST server, I don't think we can indicate that Request URI or URI in the Route header is the PSAP URI derived as a result of LoST mapping/query... I think any marking that will prioritize the call should be traceable to who had marked the call in case it was used to DoS or used maliciously. I like the idea of putting the Service URN in the To header which then can be signed with SIP-identity by the proxy serving the UA making the emergency call. With the proxy conducting the LoST query, it could make sure that the destination set as a value in Route header is indeed a PSAP URI(In case UA has queried the LoST prior to making the call) and sign the message only when it confirms that the call is indeed an emergency call. Regards Shida Brian Rosen wrote: > If you leave the service URN in the Request URI, how do you know whether any > LoST mapping has been performed? That is, how do you know whether a new, > more specific next hop needs to be computed? Presence of a Route header > doesn't seem to be a good indication. > > I do agree on your separation of marking aspects. > > Brian > > >> -----Original Message----- >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> Sent: Tuesday, September 19, 2006 10:58 AM >> To: John Rosenberg >> Cc: Brian Rosen; 'Andrew Newton'; 'Ecrit@Ietf.Org' >> Subject: Re: [Ecrit] Identifying 911 calls and avoid congestion for 911 >> calls >> >> I think we should distinguish several aspects, i.e., what's the purpose >> of marking? >> >> - indicate routing requests (applies to any service URN, not just >> emergency); in particular, whether a new, more specific, next hop needs >> to be computed >> >> - indicate priority handling (applies only to emergency, but maybe not >> test calls) >> >> The Route/Request-URI behavior I suggested is standard SIP RFC 3261 >> behavior, not anything new. >> >> John Rosenberg wrote: >> >>> Using Resource-Priority is and interesting suggestion. RPH does have an >>> element of call-type identification based on the namespace value. >>> However, RPH's main goal is to communicate a priority level to be used >>> in conjunction with resource allocation, especially during congestion or >>> in the face of resource contention - not quite what we're doing here. >>> >>> I know that at least one service provider is suggesting the use of a >>> mode=emergency tag in the R-URI. >>> >>> John Rosenberg >>> >>> >>> >>> >>> At 08:10 AM 9/19/2006, Brian Rosen wrote: >>> >Having thought through this, I think it's a lousy idea. >>> > >>> >The reason is that EVERY element between the endpoint and the PSAP >>> must be >>> >upgraded to have new behavior = recognize the service URN, "ignore" >>> it, and >>> >route based on the route header. It really violates the spirit of >>> >> 3261 >> >>> >where you can safely ignore things you don't understand, recognizing >>> >> that >> >>> >proxies have to be able to deal with the URN in the Request URI for as >>> long >>> >as it's there. >>> > >>> >I think a Resource Priority header would have the right >>> characteristics. It >>> >could also serve for a call back placed by a PSAP towards an endpoint. >>> > >>> >Brian >>> > >>> > > > _______________________________________________ > 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 Sep 19 22:49:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPs8n-0006wS-AK; Tue, 19 Sep 2006 22:48:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPs8l-0006wE-Uk for ecrit@ietf.org; Tue, 19 Sep 2006 22:48:47 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPs8k-0005iY-MS for ecrit@ietf.org; Tue, 19 Sep 2006 22:48:47 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Sep 2006 21:48:43 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Tue, 19 Sep 2006 21:48:42 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Sep 2006 21:48:41 -0500 Message-ID: From: "Winterbottom, James" To: Date: Tue, 19 Sep 2006 21:48:39 -0500 Subject: FW: [Ecrit] Hum for draft-polk-ecrit-dhc-lost-discovery-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 20 Sep 2006 02:48:41.0703 (UTC) FILETIME=[48250F70:01C6DC5F] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Hum for draft-polk-ecrit-dhc-lost-discovery-00.txt Thread-Index: AcbcBA8nnL0TgDrmSdiMd2np/2AKNQAPF+qQAAeyk9A= X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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: , Errors-To: ecrit-bounces@ietf.org Hi Hannes, HUM in the affirmative. A point to note with your examples. I suspect that in many cases LoST servers will be at the national level, consequently will have domains like .gov.au having examples that reflect these rather than just .com or .net may help to make this more clear. Cheers James > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Wednesday, 20 September 2006 1:56 AM > To: Marc Linsner > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Hum for draft-polk-ecrit-dhc-lost-discovery-00.txt >=20 > Please respond since we want to finish the LoST as soon as possible. > Comments on the LoST draft are also very much appreciated. >=20 > Marc Linsner schrieb: > > Please read this and express a hum for or against accepting as a wg > item. > > I'll count hums at the end of this week. > > > > > > Title : A Dynamic Host Configuration Protocol (DHCP) > > based Location-to-Service Translation > > Protocol (LoST) Discovery Procedure > > Author(s) : H. Schulzrinne, et al. > > Filename : draft-polk-ecrit-dhc-lost-discovery-00.txt > > Pages : 17 > > Date : 2006-9-5 > > > > > > Thanks, > > > > -Marc- > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 19 23:26:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPsjE-0002gi-KK; Tue, 19 Sep 2006 23:26:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPsjD-0002ga-Nl for ecrit@ietf.org; Tue, 19 Sep 2006 23:26:27 -0400 Received: from static-68-162-93-99.phil.east.verizon.net ([68.162.93.99] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GPsjC-0001Zt-9Y for ecrit@ietf.org; Tue, 19 Sep 2006 23:26:27 -0400 Received: from [10.71.2.159] ([10.71.2.159]) by localhost 0.5.5 with ESMTP id 0C96451051F00000 Tue Sep 19 23:24:17 2006 Message-ID: <4510B4E4.5080907@gmx.net> Date: Tue, 19 Sep 2006 23:26:28 -0400 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Winterbottom, James" Subject: Re: FW: [Ecrit] Hum for draft-polk-ecrit-dhc-lost-discovery-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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: , Errors-To: ecrit-bounces@ietf.org Hi James, thanks for the response. Regarding the example: You are certainly right. However, http://www.ietf.org/ID-Checklist.html tells me that I should preferable use FQDNs such as the one I used. Ciao Hannes Winterbottom, James schrieb: > Hi Hannes, > > HUM in the affirmative. > > A point to note with your examples. > I suspect that in many cases LoST servers will be at the national level, > consequently will have domains like .gov.au having examples that reflect > these rather than just .com or .net may help to make this more clear. > > Cheers > James > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Wednesday, 20 September 2006 1:56 AM >> To: Marc Linsner >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] Hum for > draft-polk-ecrit-dhc-lost-discovery-00.txt >> Please respond since we want to finish the LoST as soon as possible. >> Comments on the LoST draft are also very much appreciated. >> >> Marc Linsner schrieb: >>> Please read this and express a hum for or against accepting as a wg >> item. >>> I'll count hums at the end of this week. >>> >>> >>> Title : A Dynamic Host Configuration Protocol (DHCP) >>> based Location-to-Service Translation >>> Protocol (LoST) Discovery Procedure >>> Author(s) : H. Schulzrinne, et al. >>> Filename : draft-polk-ecrit-dhc-lost-discovery-00.txt >>> Pages : 17 >>> Date : 2006-9-5 >>> >>> >>> Thanks, >>> >>> -Marc- >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 20 05:44:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPych-0000PR-V0; Wed, 20 Sep 2006 05:44:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPych-0000OF-8u for ecrit@ietf.org; Wed, 20 Sep 2006 05:44:07 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPycX-0004pO-SY for ecrit@ietf.org; Wed, 20 Sep 2006 05:44:07 -0400 Received: from ([139.76.131.83]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.162379972; Wed, 20 Sep 2006 05:43:37 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010622.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 20 Sep 2006 05:43:37 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 20 Sep 2006 05:43:36 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls Date: Wed, 20 Sep 2006 05:43:36 -0400 Importance: normal Priority: normal Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA2F169A@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls Thread-Index: Acbb/EMvB4uxj0IjRSKhw9A2m29+RwAmcVc3 References: <00ce01c6dbec$ecbea640$7647540a@cis.neustar.com><6.2.1.2.0.20060919081753.034c0028@ihmail.ih.lucent.com> <45100591.6040609@cs.columbia.edu> From: "Stark, Barbara" To: "Henning Schulzrinne" , "John Rosenberg" X-OriginalArrivalTime: 20 Sep 2006 09:43:36.0874 (UTC) FILETIME=[3ED2B0A0:01C6DC99] X-Spam-Score: 0.2 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c 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: , Content-Type: multipart/mixed; boundary="===============1402783774==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1402783774== Content-class: urn:content-classes:message Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6DC99.3E9A391B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6DC99.3E9A391B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > I think we should distinguish several aspects, i.e., what's the = purpose of marking? > ... > - indicate priority handling (applies only to emergency, but maybe not = test calls) =20 I don't think I'd really be in favor of using this to indicate priority = handling in any of the network elements we operate. It certainly makes = no sense in IP routers that handle general data or Internet traffic. = That is, I wouldn't want to impact the performance of these high = capacity routers by making them become SIP-aware and have to look inside = the SIP to determine prioritization. For these devices, DSCP is where = it's at. =20 The only devices where it might make sense, would be the ones that are = currently SIP-aware, like the Session/Border Controllers (SBC) and the = proxies. I think I'd still prefer to use DSCP. I've heard rumors of = discussions around maybe, possibly creating a new EF-like DSCP for = emergency services?=20 =20 Also (and please, correct me if I'm wrong, because I'm a bit out of my = element here), it seems that this would only be useful for the SIP = messages from the user to the PSAP, but not the return messages? =20 With that said, I know that our SBCs have firewall capabilities and DSCP = marking/remarking capabilities. If this were used as something that SBCs = looked at when checking whether the DSCP marking was proper (and then = remark if not), that might be ok. But these rules on what the SBC looks = at and does with the things it sees are very flexible and constantly = changing. So I wouldn't expect such a usage to be written in concrete. Barbara ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA622 ------_=_NextPart_001_01C6DC99.3E9A391B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: [Ecrit] Identifying 911 calls and avoid congestion for 911 = calls=0A= =0A= =0A=
=0A=
> I think we should distinguish several = aspects, =0A= i.e., what's the purpose of marking?
=0A=
> ...
=0A=
> - indicate priority handling (applies = only to =0A= emergency, but maybe not test calls)
=0A=
 
=0A=
I don't think I'd really be in favor of = using this to =0A= indicate priority handling in any of the network elements we operate. It =0A= certainly makes no sense in IP routers that handle general data or = Internet =0A= traffic. That is, I wouldn't want to impact the performance of these = high =0A= capacity routers by making them become SIP-aware and have to look inside = the SIP =0A= to determine prioritization. For these devices, DSCP is where it's =0A= at.
=0A=
 
=0A=
The only devices where it might make = sense, would be =0A= the ones that are currently SIP-aware, like the Session/Border = Controllers (SBC) =0A= and the proxies. I think I'd still prefer to use DSCP. I've heard rumors = of =0A= discussions around maybe, possibly creating a new EF-like DSCP for = emergency =0A= services?
=0A=
 
=0A=
Also (and please, correct me if I'm wrong, = because I'm =0A= a bit out of my element here), it seems that this would only be useful = for the =0A= SIP messages from the user to the PSAP, but not the return =0A= messages?
=0A=
 
=0A=
With that said, I know that our SBCs have = firewall =0A= capabilities and DSCP marking/remarking capabilities. If this were used = as =0A= something that SBCs looked at when checking whether the DSCP marking was = proper =0A= (and then remark if not), that might be ok. But these rules on what the = SBC =0A= looks at and does with the things it sees are very flexible and = constantly =0A= changing. So I wouldn't expect such a usage to be written in =0A= concrete.
=0A=
Barbara
=0A= =0A= =0A=

*****

The information = transmitted is intended only for the person or entity to which it is = addressed and may contain confidential, proprietary, and/or privileged = material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon this information by persons or = entities other than the intended recipient is prohibited. If you = received this in error, please contact the sender and delete the = material from all computers. GA622

 ------_=_NextPart_001_01C6DC99.3E9A391B-- --===============1402783774== 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 --===============1402783774==-- From ecrit-bounces@ietf.org Wed Sep 20 07:48:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ0Xw-000446-LD; Wed, 20 Sep 2006 07:47:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ0Xu-00043z-If for ecrit@ietf.org; Wed, 20 Sep 2006 07:47:18 -0400 Received: from ns.xittelecom.com ([205.151.16.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ0Xs-0001Me-8f for ecrit@ietf.org; Wed, 20 Sep 2006 07:47:18 -0400 Received: from fmenard (helo=localhost) by ns.xittelecom.com with local-esmtp (Exim 3.36 #1 (Debian)) id 1GQ0Wv-0000Qj-00; Wed, 20 Sep 2006 06:46:17 -0500 Date: Wed, 20 Sep 2006 06:46:17 -0500 (EST) From: Francois Menard X-X-Sender: fmenard@localhost To: "Stark, Barbara" Subject: RE: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA2F169A@crexc41p> Message-ID: References: <00ce01c6dbec$ecbea640$7647540a@cis.neustar.com><6.2.1.2.0.20060919081753.034c0028@ihmail.ih.lucent.com> <45100591.6040609@cs.columbia.edu> <7582BC68E4994F4ABF0BD4723975C3FA2F169A@crexc41p> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: , Errors-To: ecrit-bounces@ietf.org That would not be too different from the HPC (High-Probability of Call Completion) implemented on the 1-710-NXX-XXXX PSTN network (that we never got around to agree how to implement in Canada). The Government of Canada even bought two Class 5 switches in the CRC labs in Ottawa to attempt to figure out how it should subsidize this (I hear). F. -- Francois D. Menard Project Manager/Charge de projet Xit telecom inc. 1350 Royale # 800 Trois-Rivieres, QC, G9A 4J4 Tel: +1 819 374 2556 x 268 Cell: +1 819 692 1383 fmenard@xittelecom.com On Wed, 20 Sep 2006, Stark, Barbara wrote: >> I think we should distinguish several aspects, i.e., what's the purpose of marking? >> ... >> - indicate priority handling (applies only to emergency, but maybe not test calls) > > I don't think I'd really be in favor of using this to indicate priority handling in any of the network elements we operate. It certainly makes no sense in IP routers that handle general data or Internet traffic. That is, I wouldn't want to impact the performance of these high capacity routers by making them become SIP-aware and have to look inside the SIP to determine prioritization. For these devices, DSCP is where it's at. > > The only devices where it might make sense, would be the ones that are currently SIP-aware, like the Session/Border Controllers (SBC) and the proxies. I think I'd still prefer to use DSCP. I've heard rumors of discussions around maybe, possibly creating a new EF-like DSCP for emergency services? > > Also (and please, correct me if I'm wrong, because I'm a bit out of my element here), it seems that this would only be useful for the SIP messages from the user to the PSAP, but not the return messages? > > With that said, I know that our SBCs have firewall capabilities and DSCP marking/remarking capabilities. If this were used as something that SBCs looked at when checking whether the DSCP marking was proper (and then remark if not), that might be ok. But these rules on what the SBC looks at and does with the things it sees are very flexible and constantly changing. So I wouldn't expect such a usage to be written in concrete. > Barbara > > ***** > > The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622 > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 20 08:36:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ1Im-00073c-OZ; Wed, 20 Sep 2006 08:35:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ1Il-0006uy-4a for ecrit@ietf.org; Wed, 20 Sep 2006 08:35:43 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ1Ij-00089c-SR for ecrit@ietf.org; Wed, 20 Sep 2006 08:35:43 -0400 Received: from [192.168.0.41] (pool-141-153-175-20.mad.east.verizon.net [141.153.175.20]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k8KCZbGl013112 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 20 Sep 2006 08:35:39 -0400 (EDT) In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA2F169A@crexc41p> References: <00ce01c6dbec$ecbea640$7647540a@cis.neustar.com><6.2.1.2.0.20060919081753.034c0028@ihmail.ih.lucent.com> <45100591.6040609@cs.columbia.edu> <7582BC68E4994F4ABF0BD4723975C3FA2F169A@crexc41p> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4F88EE38-AAC3-43AE-BB46-967AE08D0B6C@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls Date: Wed, 20 Sep 2006 08:35:29 -0400 To: "Stark, Barbara" X-Mailer: Apple Mail (2.752.2) X-PerlMx-Spam: Gauge=XXII, Probability=22%, X-Seen-By filter1.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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: , Errors-To: ecrit-bounces@ietf.org On Sep 20, 2006, at 5:43 AM, Stark, Barbara wrote: > > I think we should distinguish several aspects, i.e., what's the > purpose of marking? > > ... > > - indicate priority handling (applies only to emergency, but > maybe not test calls) > > I don't think I'd really be in favor of using this to indicate > priority handling in any of the network elements we operate. It > certainly makes no sense in IP routers that handle general data or > Internet traffic. That is, I wouldn't want to impact the > performance of these high capacity routers by making them become > SIP-aware and have to look inside the SIP to determine > prioritization. For these devices, DSCP is where it's at. I don't think anybody is proposing this, but maybe I'm biased by the discussion in the Resource-Priority RFC (RFC 4412), which explicitly rules out any attempt to use R-P for DiffServ-like behaviors. > > The only devices where it might make sense, would be the ones that > are currently SIP-aware, like the Session/Border Controllers (SBC) > and the proxies. I think I'd still prefer to use DSCP. I've heard > rumors of discussions around maybe, possibly creating a new EF-like > DSCP for emergency services? These are completely different issues. Any R-P would affect SIP processing only; the only connection to packet-level prioritization would be that the proxy could mark outgoing signaling packets with a "better" DSCP. Saying "just use DSCP" doesn't quite work since the marking of the inbound INVITE packet would be lost as soon as that packet hits the first proxy. The IEPREP WG has been working on this topic, but is currently in hiatus. > > Also (and please, correct me if I'm wrong, because I'm a bit out of > my element here), it seems that this would only be useful for the > SIP messages from the user to the PSAP, but not the return messages? Please see the discussion in RFC 4412 on this topic. > > With that said, I know that our SBCs have firewall capabilities and > DSCP marking/remarking capabilities. If this were used as something > that SBCs looked at when checking whether the DSCP marking was > proper (and then remark if not), that might be ok. But these rules > on what the SBC looks at and does with the things it sees are very > flexible and constantly changing. So I wouldn't expect such a usage > to be written in concrete. > Barbara > ***** > > The information transmitted is intended only for the person or > entity to which it is addressed and may contain confidential, > proprietary, and/or privileged material. Any review, > retransmission, dissemination or other use of, or taking of any > action in reliance upon this information by persons or entities > other than the intended recipient is prohibited. If you received > this in error, please contact the sender and delete the material > from all computers. GA622 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 20 09:54:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ2W1-0006hp-3E; Wed, 20 Sep 2006 09:53:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ2Vz-0006hk-Ox for ecrit@ietf.org; Wed, 20 Sep 2006 09:53:27 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ2Vx-0000bL-Dj for ecrit@ietf.org; Wed, 20 Sep 2006 09:53:27 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail3.lucent.com (8.13.6/IER-o) with ESMTP id k8KDrFTA010921; Wed, 20 Sep 2006 08:53:19 -0500 (CDT) Received: from jrrosenberg-04.lucent.com (jrrosenberg-04.ih.lucent.com [135.185.233.167]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k8KDrDV01959; Wed, 20 Sep 2006 08:53:13 -0500 (CDT) Message-Id: <6.2.1.2.0.20060920084925.03562430@ihmail.ih.lucent.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 20 Sep 2006 08:53:12 -0500 To: Henning Schulzrinne , "Stark, Barbara" From: John Rosenberg Subject: Re: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls In-Reply-To: <4F88EE38-AAC3-43AE-BB46-967AE08D0B6C@cs.columbia.edu> References: <00ce01c6dbec$ecbea640$7647540a@cis.neustar.com> <6.2.1.2.0.20060919081753.034c0028@ihmail.ih.lucent.com> <45100591.6040609@cs.columbia.edu> <7582BC68E4994F4ABF0BD4723975C3FA2F169A@crexc41p> <4F88EE38-AAC3-43AE-BB46-967AE08D0B6C@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , Errors-To: ecrit-bounces@ietf.org At 07:35 AM 9/20/2006, Henning Schulzrinne wrote: > >On Sep 20, 2006, at 5:43 AM, Stark, Barbara wrote: > >I don't think anybody is proposing this, but maybe I'm biased by the >discussion in the Resource-Priority RFC (RFC 4412), which explicitly >rules out any attempt to use R-P for DiffServ-like behaviors. > > >> >> The only devices where it might make sense, would be the ones that >> are currently SIP-aware, like the Session/Border Controllers (SBC) >> and the proxies. I think I'd still prefer to use DSCP. I've heard >> rumors of discussions around maybe, possibly creating a new EF-like >> DSCP for emergency services? > >These are completely different issues. Any R-P would affect SIP >processing only; the only connection to packet-level prioritization >would be that the proxy could mark outgoing signaling packets with a >"better" DSCP. An important related issue here is how a call controller might instruct an endpoint regarding what DSCP value the endpoint should for the bearer packets that it generates. We're running into that issue with MLPP (a user of RPH). RPH is great for doing good things to the signaling at the application layer, but really has no impact on the lower layers and no impact on the bearer stream. Anyone know of a good mechanism in SIP to tell an endpoint "use DSCP value 51 in your bearer packets"? This would be needed for emergency service calling, GETS/ETS (ieprep), and MLPP. Thanks, John Rosenberg _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 20 10:12:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ2oJ-0004S9-Rx; Wed, 20 Sep 2006 10:12:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ2oI-0004Rs-KY for ecrit@ietf.org; Wed, 20 Sep 2006 10:12:22 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ2oC-0003jo-CH for ecrit@ietf.org; Wed, 20 Sep 2006 10:12:22 -0400 Received: from [172.16.10.86] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Wed, 20 Sep 2006 10:12:05 -0400 id 015880FA.45114C35.00006312 Message-ID: <45114C31.1060901@hxr.us> Date: Wed, 20 Sep 2006 10:12:01 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] Hum for draft-polk-ecrit-dhc-lost-discovery-00.txt References: <000001c6db7c$03db01f0$1152150a@amer.cisco.com> <45102B8C.5080803@gmx.net> <45102D53.5020205@gmx.net> In-Reply-To: <45102D53.5020205@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Leslie Daigle , "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: , Errors-To: ecrit-bounces@ietf.org Hannes Tschofenig wrote: > We used the procedure used in RFC 3361 and from RFC 3319. > > RFC 3361 > Dynamic Host Configuration Protocol (DHCP-for-IPv4) > Option for Session Initiation Protocol (SIP) Servers > > RFC 3319 > > Dynamic Host Configuration Protocol (DHCPv6) Options > for Session Initiation Protocol (SIP) Servers Yes, it looks very similar. But the usages for SIP and LoST are very different. The problem is that your LoST location configuration with DHCP is actually non-interoperable with the current LoST specification. dhc-lost-discovery describes three methods of configuration: 1) IP address(es). 2) A record lookup. 3) Multiple NAPTR record lookups. The problem with the 1 and 2 is that they don't do enough. The U-NAPTR resolution specified in LoST could, and likely should, result in HTTP URIs that use ports other than 80 with specific query paths. As an example: https://example.com:4433/lost/. Neither an IP address nor an A record is enough information to construct that URI. The problem with option 3 is that it fails to understand how DNS and U-NAPTR work. Your specification says that when multiple DNS qnames are present, they are used to query multiple NAPTR records. Why? The query against one qname can result in multiple NAPTR records. What's the purpose of adding a layer above the U-NAPTR algorithm? I can only conclude that this draft is incompatible with the work already accepted by ECRIT, and therefore should not be accepted as a working group item until it is fixed. To be quite clear, I like the idea of using DHCP to configure a pointer to the LoST server, and I'd be in favor of working group acceptance of a document that did it in a way compatible with LoST. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 20 10:17:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ2tL-0007bB-1e; Wed, 20 Sep 2006 10:17:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ2tJ-0007VO-Hu for ecrit@ietf.org; Wed, 20 Sep 2006 10:17:33 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ2tI-0004US-7X for ecrit@ietf.org; Wed, 20 Sep 2006 10:17:33 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GQ2rl-0008CN-H5; Wed, 20 Sep 2006 09:15:57 -0500 From: "Brian Rosen" To: "'John Rosenberg'" , "'Henning Schulzrinne'" , "'Stark, Barbara'" Subject: RE: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls Date: Wed, 20 Sep 2006 10:17:21 -0400 Message-ID: <034601c6dcbf$7f638290$7e0210ac@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <6.2.1.2.0.20060920084925.03562430@ihmail.ih.lucent.com> Thread-Index: AcbcvA3Kc75+pMS7Q6qGTuywPzcQ2QAAwEkg X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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: , Errors-To: ecrit-bounces@ietf.org I believe you do both: You mark the SIP signaling for priority handling within the sip processing elements You mark the SIP and media packets for priority handling within the packet processing elements. It's not a good idea to infer one from the other, and it's not hard to have both markings. I don't think we should have a protocol mechanism to tell elements how to mark packets. We should choose a marking, and write it into the specification. The PHB for the marking would have to be a local matter. Brian > -----Original Message----- > From: John Rosenberg [mailto:jrrosenberg@lucent.com] > Sent: Wednesday, September 20, 2006 9:53 AM > To: Henning Schulzrinne; Stark, Barbara > Cc: Ecrit@Ietf.Org > Subject: Re: [Ecrit] Identifying 911 calls and avoid congestion for 911 > calls > > At 07:35 AM 9/20/2006, Henning Schulzrinne wrote: > > > >On Sep 20, 2006, at 5:43 AM, Stark, Barbara wrote: > > > > >I don't think anybody is proposing this, but maybe I'm biased by the > >discussion in the Resource-Priority RFC (RFC 4412), which explicitly > >rules out any attempt to use R-P for DiffServ-like behaviors. > > > > > >> > >> The only devices where it might make sense, would be the ones that > >> are currently SIP-aware, like the Session/Border Controllers (SBC) > >> and the proxies. I think I'd still prefer to use DSCP. I've heard > >> rumors of discussions around maybe, possibly creating a new EF-like > >> DSCP for emergency services? > > > >These are completely different issues. Any R-P would affect SIP > >processing only; the only connection to packet-level prioritization > >would be that the proxy could mark outgoing signaling packets with a > >"better" DSCP. > > An important related issue here is how a call controller might instruct an > endpoint regarding what DSCP value the endpoint should for the bearer > packets that it generates. We're running into that issue with MLPP (a user > of RPH). > > RPH is great for doing good things to the signaling at the application > layer, but really has no impact on the lower layers and no impact on the > bearer stream. > > Anyone know of a good mechanism in SIP to tell an endpoint "use DSCP value > 51 in your bearer packets"? > > This would be needed for emergency service calling, GETS/ETS (ieprep), and > MLPP. > > Thanks, > > John Rosenberg > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 20 10:36:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ3BU-0006aJ-R1; Wed, 20 Sep 2006 10:36:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ3BT-0006a8-2r for ecrit@ietf.org; Wed, 20 Sep 2006 10:36:19 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ3BI-0007Pc-M6 for ecrit@ietf.org; Wed, 20 Sep 2006 10:36:19 -0400 Received: from ([139.76.131.83]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.162405837; Wed, 20 Sep 2006 10:35:42 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010622.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 20 Sep 2006 10:35:42 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 20 Sep 2006 10:35:42 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Hum for draft-polk-ecrit-dhc-lost-discovery-00.txt Date: Wed, 20 Sep 2006 10:35:28 -0400 Importance: normal Priority: normal Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA2F169D@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Hum for draft-polk-ecrit-dhc-lost-discovery-00.txt Thread-Index: AcbbZ8yDNqEfdYBnR8am9U6D/lORowBWjfjj References: <000001c6db7c$03db01f0$1152150a@amer.cisco.com> From: "Stark, Barbara" To: "Marc Linsner" , X-OriginalArrivalTime: 20 Sep 2006 14:35:42.0247 (UTC) FILETIME=[0CC26370:01C6DCC2] X-Spam-Score: 0.2 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 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="===============1606940644==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1606940644== Content-class: urn:content-classes:message Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6DCC2.0C8A63FB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6DCC2.0C8A63FB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree. Barbara ________________________________ From: Marc Linsner [mailto:mlinsner@cisco.com] Sent: Mon 9/18/2006 7:41 PM To: ecrit@ietf.org Subject: [Ecrit] Hum for draft-polk-ecrit-dhc-lost-discovery-00.txt Please read this and express a hum for or against accepting as a wg = item. I'll count hums at the end of this week. Title : A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service Translation Protocol (LoST) Discovery Procedure Author(s) : H. Schulzrinne, et al. Filename : draft-polk-ecrit-dhc-lost-discovery-00.txt Pages : 17 Date : 2006-9-5 Thanks, -Marc-=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA622 ------_=_NextPart_001_01C6DCC2.0C8A63FB Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= [Ecrit] Hum for draft-polk-ecrit-dhc-lost-discovery-00.txt=0A= =0A= =0A=
=0A=
I = agree.
=0A=
Barbara
=0A=

=0A=
=0A= From: Marc Linsner =0A= [mailto:mlinsner@cisco.com]
Sent: Mon 9/18/2006 7:41 = PM
To: =0A= ecrit@ietf.org
Subject: [Ecrit] Hum for =0A= draft-polk-ecrit-dhc-lost-discovery-00.txt

=0A=
=0A=

Please read this and express a hum for or against = accepting as a =0A= wg item.
I'll count hums at the end of this =0A= week.


      = Title     =0A=         : A Dynamic Host = Configuration =0A= Protocol =0A= (DHCP)
          &nb= sp;           &nbs= p;    =0A= based Location-to-Service =0A= Translation
         &nbs= p;            = ;     =0A= Protocol (LoST) Discovery =0A= Procedure
        =0A= Author(s)       : H. Schulzrinne, et =0A= al.
        =0A= Filename        : =0A= draft-polk-ecrit-dhc-lost-discovery-00.txt
    &nb= sp;   =0A= Pages           : =0A= 17
        Date    =0A=         : =0A= 2006-9-5


Thanks,

-Marc- 

__________________= _____________________________
Ecrit =0A= mailing list
Ecrit@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/ecrit

=0A= =0A= =0A=

*****

The information = transmitted is intended only for the person or entity to which it is = addressed and may contain confidential, proprietary, and/or privileged = material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon this information by persons or = entities other than the intended recipient is prohibited. If you = received this in error, please contact the sender and delete the = material from all computers. GA622

 ------_=_NextPart_001_01C6DCC2.0C8A63FB-- --===============1606940644== 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 --===============1606940644==-- From ecrit-bounces@ietf.org Wed Sep 20 10:39:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ3Ec-0007IC-U6; Wed, 20 Sep 2006 10:39:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ3Eb-0007I7-Ec for ecrit@ietf.org; Wed, 20 Sep 2006 10:39:33 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ3Ea-00080P-8Z for ecrit@ietf.org; Wed, 20 Sep 2006 10:39:33 -0400 Received: from lion.cs.columbia.edu (IDENT:53UbKZzxNILBU+h/ulXrLRrACXCNrFJ3@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k8KEdSGb004298 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 20 Sep 2006 10:39:28 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k8KEdRg7016369 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Sep 2006 10:39:27 -0400 Message-ID: <4511529A.5000803@cs.columbia.edu> Date: Wed, 20 Sep 2006 10:39:22 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: John Rosenberg Subject: Re: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls References: <00ce01c6dbec$ecbea640$7647540a@cis.neustar.com> <6.2.1.2.0.20060919081753.034c0028@ihmail.ih.lucent.com> <45100591.6040609@cs.columbia.edu> <7582BC68E4994F4ABF0BD4723975C3FA2F169A@crexc41p> <4F88EE38-AAC3-43AE-BB46-967AE08D0B6C@cs.columbia.edu> <6.2.1.2.0.20060920084925.03562430@ihmail.ih.lucent.com> In-Reply-To: <6.2.1.2.0.20060920084925.03562430@ihmail.ih.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter1.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: "Stark, Barbara" , "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: , Errors-To: ecrit-bounces@ietf.org > Anyone know of a good mechanism in SIP to tell an endpoint "use DSCP > value 51 in your bearer packets"? > > This would be needed for emergency service calling, GETS/ETS (ieprep), > and MLPP. This isn't really a SIP function; at best, this is the territory of SDP. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 20 10:48:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ3NR-0004CO-53; Wed, 20 Sep 2006 10:48:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ3NP-0004CJ-Ni for ecrit@ietf.org; Wed, 20 Sep 2006 10:48:39 -0400 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ3NK-0001L0-BP for ecrit@ietf.org; Wed, 20 Sep 2006 10:48:39 -0400 Received: from ([139.76.131.79]) by aismt06p.bellsouth.com with SMTP id KP-AXPRN.7608085; Wed, 20 Sep 2006 10:48:08 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 20 Sep 2006 10:46:50 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 20 Sep 2006 10:46:50 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls Date: Wed, 20 Sep 2006 10:46:49 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA2F169E@crexc41p> Importance: normal Priority: normal X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls Thread-Index: AcbcwqHDIY9kwsWdTkKck3e2U3KnkAAACCbS References: <00ce01c6dbec$ecbea640$7647540a@cis.neustar.com> <6.2.1.2.0.20060919081753.034c0028@ihmail.ih.lucent.com> <45100591.6040609@cs.columbia.edu> <7582BC68E4994F4ABF0BD4723975C3FA2F169A@crexc41p> <4F88EE38-AAC3-43AE-BB46-967AE08D0B6C@cs.columbia.edu> <6.2.1.2.0.20060920084925.03562430@ihmail.ih.lucent.com> <4511529A.5000803@cs.columbia.edu> From: "Stark, Barbara" To: "Henning Schulzrinne" , "John Rosenberg" X-OriginalArrivalTime: 20 Sep 2006 14:46:50.0074 (UTC) FILETIME=[9AD0B3A0:01C6DCC3] X-Spam-Score: 0.2 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 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: , Content-Type: multipart/mixed; boundary="===============1441645223==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1441645223== Content-class: urn:content-classes:message Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6DCC3.9AB4A19B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6DCC3.9AB4A19B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Is there an expectation that the DSCP value will change from region to = region? If not, and given that the endpoint is responsible for identifying = emergency calls, I'd rather it just be pre-configured with the correct = DSCP to use for emergency calls (SIP and RTP). If it will different, then that will cause undesirable behavior, because = many of the network elements processing the call may not be in the same = region as the call originator and call taker. Barbara ________________________________ From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Wed 9/20/2006 10:39 AM To: John Rosenberg Cc: Stark, Barbara; Ecrit@Ietf.Org Subject: Re: [Ecrit] Identifying 911 calls and avoid congestion for 911 = calls > Anyone know of a good mechanism in SIP to tell an endpoint "use DSCP > value 51 in your bearer packets"? > > This would be needed for emergency service calling, GETS/ETS (ieprep), > and MLPP. This isn't really a SIP function; at best, this is the territory of SDP. ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA621 ------_=_NextPart_001_01C6DCC3.9AB4A19B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: [Ecrit] Identifying 911 calls and avoid congestion for 911 = calls=0A= =0A= =0A=
=0A=
Is there an = expectation that =0A= the DSCP value will change from region to region?
=0A=
If not, and given that the = endpoint is =0A= responsible for identifying emergency calls, I'd rather it just be =0A= pre-configured with the correct DSCP to use for emergency calls (SIP and =0A= RTP).
=0A=
If it will different, then = that will cause =0A= undesirable behavior, because many of the network elements processing = the call =0A= may not be in the same region as the call originator and call =0A= taker.
=0A=
Barbara
=0A=

=0A=
=0A= From: Henning Schulzrinne =0A= [mailto:hgs@cs.columbia.edu]
Sent: Wed 9/20/2006 10:39 =0A= AM
To: John Rosenberg
Cc: Stark, Barbara; =0A= Ecrit@Ietf.Org
Subject: Re: [Ecrit] Identifying 911 calls and = avoid =0A= congestion for 911 calls

=0A=
=0A=

> Anyone know of a good mechanism in SIP to tell an = endpoint =0A= "use DSCP
> value 51 in your bearer packets"?
>
> This = would =0A= be needed for emergency service calling, GETS/ETS (ieprep),
> and =0A= MLPP.

This isn't really a SIP function; at best, this is the = territory of =0A= SDP.

=0A= =0A= =0A=

*****

The information = transmitted is intended only for the person or entity to which it is = addressed and may contain confidential, proprietary, and/or privileged = material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon this information by persons or = entities other than the intended recipient is prohibited. If you = received this in error, please contact the sender and delete the = material from all computers. GA621

 ------_=_NextPart_001_01C6DCC3.9AB4A19B-- --===============1441645223== 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 --===============1441645223==-- From ecrit-bounces@ietf.org Wed Sep 20 18:29:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQAY1-0001Od-9c; Wed, 20 Sep 2006 18:28:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQAY0-0001OU-5g for ecrit@ietf.org; Wed, 20 Sep 2006 18:28:04 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQAXf-0002yy-BU for ecrit@ietf.org; Wed, 20 Sep 2006 18:27:44 -0400 Received: from [192.168.0.109] ([::ffff:64.102.254.33]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Wed, 20 Sep 2006 18:27:07 -0400 id 01588113.4511C03B.000043F8 Message-ID: <4511C03D.9040100@thinkingcat.com> Date: Wed, 20 Sep 2006 18:27:09 -0400 From: Leslie Daigle User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] Hum for draft-polk-ecrit-dhc-lost-discovery-00.txt References: <000001c6db7c$03db01f0$1152150a@amer.cisco.com> <45102B8C.5080803@gmx.net> <45102D53.5020205@gmx.net> <45114C31.1060901@hxr.us> In-Reply-To: <45114C31.1060901@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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: , Errors-To: ecrit-bounces@ietf.org Further -- as noted in all the DDDS documentation, NAPTR records don't exist "in the wild"; they are always part of a DDDS application (in this case, U-NAPTR). So -- it seems that the 3rd option should really be about specifying the application unique string that feeds into the U-NAPTR-based LoST discovery specification. The application unique string would, in fact, be an FQDN. If you really need another layer of indirection (and I suspect Andy is right, you don't), you could still have multiple AUS's. Leslie. Andrew Newton wrote: > Hannes Tschofenig wrote: >> We used the procedure used in RFC 3361 and from RFC 3319. >> >> RFC 3361 >> Dynamic Host Configuration Protocol (DHCP-for-IPv4) >> Option for Session Initiation Protocol (SIP) Servers >> >> RFC 3319 >> >> Dynamic Host Configuration Protocol (DHCPv6) Options >> for Session Initiation Protocol (SIP) Servers > > Yes, it looks very similar. But the usages for SIP and LoST are very > different. The problem is that your LoST location configuration with > DHCP is actually non-interoperable with the current LoST specification. > > dhc-lost-discovery describes three methods of configuration: > > 1) IP address(es). > 2) A record lookup. > 3) Multiple NAPTR record lookups. > > The problem with the 1 and 2 is that they don't do enough. The U-NAPTR > resolution specified in LoST could, and likely should, result in HTTP > URIs that use ports other than 80 with specific query paths. As an > example: https://example.com:4433/lost/. Neither an IP address nor an A > record is enough information to construct that URI. > > The problem with option 3 is that it fails to understand how DNS and > U-NAPTR work. Your specification says that when multiple DNS qnames are > present, they are used to query multiple NAPTR records. Why? The query > against one qname can result in multiple NAPTR records. What's the > purpose of adding a layer above the U-NAPTR algorithm? > > I can only conclude that this draft is incompatible with the work > already accepted by ECRIT, and therefore should not be accepted as a > working group item until it is fixed. > > To be quite clear, I like the idea of using DHCP to configure a pointer > to the LoST server, and I'd be in favor of working group acceptance of a > document that did it in a way compatible with LoST. > > -andy > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 21 03:07:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQIeY-0005t0-Qo; Thu, 21 Sep 2006 03:07:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQIeX-0005st-Qd for ecrit@ietf.org; Thu, 21 Sep 2006 03:07:21 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GQIeT-0004k5-Hg for ecrit@ietf.org; Thu, 21 Sep 2006 03:07:21 -0400 Received: (qmail invoked by alias); 21 Sep 2006 07:07:16 -0000 Received: from ip-80-226-194-40.vodafone-net.de (EHLO [10.227.54.70]) [80.226.194.40] by mail.gmx.net (mp044) with SMTP; 21 Sep 2006 09:07:16 +0200 X-Authenticated: #29516787 Message-ID: <45123A2A.9030600@gmx.net> Date: Thu, 21 Sep 2006 03:07:22 -0400 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Ecrit] REMINDER: ECRIT Implementers Mailing List 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: , Errors-To: ecrit-bounces@ietf.org Hi all, if you are working or planning to work on implementations regarding emergency services then you might want to drop us a mail. We will put your name on the ECRIT implementers mailing list. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 21 03:07:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQIeh-0005v9-1B; Thu, 21 Sep 2006 03:07:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQIef-0005th-Tt for ecrit@ietf.org; Thu, 21 Sep 2006 03:07:29 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GQIed-0004kY-HZ for ecrit@ietf.org; Thu, 21 Sep 2006 03:07:29 -0400 Received: (qmail invoked by alias); 21 Sep 2006 07:07:26 -0000 Received: from ip-80-226-194-40.vodafone-net.de (EHLO [10.227.54.70]) [80.226.194.40] by mail.gmx.net (mp007) with SMTP; 21 Sep 2006 09:07:26 +0200 X-Authenticated: #29516787 Message-ID: <45123A34.9080301@gmx.net> Date: Thu, 21 Sep 2006 03:07:32 -0400 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [Ecrit] Mapping Architecture 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: , Errors-To: ecrit-bounces@ietf.org Hi all, consider the following picture from draft-ietf-ecrit-mapping-arch-00.txt: /-\ /-\ +-----+ +-----+ | S +******* R ********* FG *-----------------+ FG | \-/ \-/ | |* | | +--+--+ * +--+--+ | * | | * | | * | | * | /-\ +--+--+ * +--+--+ | R +------>+ FG +-----*-----------+ FG | \-/ | | * | | +--+--+ * +--+--+ | * | | * | | * | |*** ^ / \ / \ / \ / \ / \ / \ / \ / \ ----------- ----------- tree tree What does each entity need to know? * Seeker: It only needs to be configured with a resolver (=LoST server). See DHCP and DNS-based mechanism (i.e., a dynamic discovery mechanism). * Resolver: It needs to be configured with the FG address, i.e., it needs to know at least one FG. Ideally, it knows which FG is responsible for which region. In this case it might just contact the right FG without contacting FGs. Additionally, the resolver might also know some other LoST servers within its tree to speed-up search. I assume that the addresses of FGs and LoST servers a resolver knows is largely based on manual configuration? The resolver will also cache service boundaries to speed up future search attempts. * Forest Guide: The FGs need to be aware of each other. This is most likely be based on manual configuration. For example, the FG is manually configured with the address of the FG in Germany. The FG also needs to know the service boundaries of each FG. This might also be exchanged out of band. Are my observations largely correct? Ciao Hannes PS: The term 'tree' is a bit misleading since it collectively refers to the LoST server below a FG. The figure only shows resolves that are part of this tree but does not depict authoritative LoST servers. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 21 16:42:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQVN8-00045J-JI; Thu, 21 Sep 2006 16:42:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQVN6-00044D-RO for ecrit@ietf.org; Thu, 21 Sep 2006 16:42:12 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQVHb-0000Yg-HE for ecrit@ietf.org; Thu, 21 Sep 2006 16:36:32 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 21 Sep 2006 16:36:31 -0400 X-IronPort-AV: i="4.09,196,1157342400"; d="scan'208,217"; a="103818392:sNHT53104974" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8LKaVLh022841; Thu, 21 Sep 2006 16:36:31 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8LKaQdO008497; Thu, 21 Sep 2006 16:36:29 -0400 (EDT) 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.1830); Thu, 21 Sep 2006 16:36:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls Date: Thu, 21 Sep 2006 16:36:26 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301F96530@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls Thread-Index: AcbcwqHDIY9kwsWdTkKck3e2U3KnkAAACCbSAD6crcA= From: "Michael Hammer \(mhammer\)" To: "Stark, Barbara" , "Henning Schulzrinne" , "John Rosenberg" X-OriginalArrivalTime: 21 Sep 2006 20:36:27.0093 (UTC) FILETIME=[9C818850:01C6DDBD] DKIM-Signature: a=rsa-sha1; q=dns; l=6348; t=1158870991; x=1159734991; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Ecrit]=20Identifying=20911=20calls=20and=20avoid=20congestion=2 0for=20911=20calls |To:=22Stark, =20Barbara=22=20, =0A=20=20=20=20=2 0=20=20=20=22Henning=20Schulzrinne=22=20, =0A=20=20=20= 20=20=20=20=20=22John=20Rosenberg=22=20; X=v=3Dcisco.com=3B=20h=3DelQK7wjXNgbMCG4fFCHa1BBe9LE=3D; b=Qx3tWYtF3p0jGpbfaXSALlxXeqcruhPL642S1r4doBw1Ik8WJMvR0X8ejUzcB4CHGIy6wAQI L3moALV3h/8a8bL1/HKl7ewuVDc+oNbfPZaHwUphVl3DVxJL7Uny2eDy; Authentication-Results: rtp-dkim-1.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 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: , Content-Type: multipart/mixed; boundary="===============1875103884==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1875103884== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6DDBD.9C59B795" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6DDBD.9C59B795 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable BTW, please keep the class of calls for (G)ETS separate from the class of calls for 911. The government folks will get upset if the emergency responders can't get their calls through the mass of 911 calls during disasters. =20 Mike =20 ________________________________ From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com]=20 Sent: Wednesday, September 20, 2006 10:47 AM To: Henning Schulzrinne; John Rosenberg Cc: Ecrit@Ietf.Org Subject: RE: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls =09 =09 Is there an expectation that the DSCP value will change from region to region? If not, and given that the endpoint is responsible for identifying emergency calls, I'd rather it just be pre-configured with the correct DSCP to use for emergency calls (SIP and RTP). If it will different, then that will cause undesirable behavior, because many of the network elements processing the call may not be in the same region as the call originator and call taker. Barbara ________________________________ From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Wed 9/20/2006 10:39 AM To: John Rosenberg Cc: Stark, Barbara; Ecrit@Ietf.Org Subject: Re: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls =09 =09 > Anyone know of a good mechanism in SIP to tell an endpoint "use DSCP > value 51 in your bearer packets"? > > This would be needed for emergency service calling, GETS/ETS (ieprep), > and MLPP. =09 This isn't really a SIP function; at best, this is the territory of SDP. =09 ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621 ------_=_NextPart_001_01C6DDBD.9C59B795 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] Identifying 911 calls and avoid = congestion for 911 calls
BTW, please keep the class of calls for (G)ETS separate = from the=20 class of calls for 911.  The government folks will get = upset if the=20 emergency responders can't get their calls through the mass of 911 calls = during=20 disasters.
 
Mike
 

From: Stark, Barbara=20 [mailto:Barbara.Stark@BellSouth.com]
Sent: Wednesday, = September 20,=20 2006 10:47 AM
To: Henning Schulzrinne; John = Rosenberg
Cc:=20 Ecrit@Ietf.Org
Subject: RE: [Ecrit] Identifying 911 calls = and avoid=20 congestion for 911 calls

Is there an = expectation=20 that the DSCP value will change from region to region?
If not, and given that the = endpoint is=20 responsible for identifying emergency calls, I'd rather it just be=20 pre-configured with the correct DSCP to use for emergency calls (SIP = and=20 RTP).
If it will different, then = that will=20 cause undesirable behavior, because many of the network elements = processing=20 the call may not be in the same region as the call originator and call = taker.
Barbara

From: Henning Schulzrinne=20 [mailto:hgs@cs.columbia.edu]
Sent: Wed 9/20/2006 10:39=20 AM
To: John Rosenberg
Cc: Stark, Barbara;=20 Ecrit@Ietf.Org
Subject: Re: [Ecrit] Identifying 911 calls = and avoid=20 congestion for 911 calls

> Anyone know of a good mechanism in SIP to tell = an=20 endpoint "use DSCP
> value 51 in your bearer = packets"?
>
>=20 This would be needed for emergency service calling, GETS/ETS = (ieprep),
>=20 and MLPP.

This isn't really a SIP function; at best, this is = the=20 territory of = SDP.

*****

The information = transmitted is=20 intended only for the person or entity to which it is addressed and = may=20 contain confidential, proprietary, and/or privileged material. Any = review,=20 retransmission, dissemination or other use of, or taking of any action = in=20 reliance upon this information by persons or entities other than the = intended=20 recipient is prohibited. If you received this in error, please contact = the=20 sender and delete the material from all computers.=20 GA621

 ------_=_NextPart_001_01C6DDBD.9C59B795-- --===============1875103884== 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 --===============1875103884==-- From ecrit-bounces@ietf.org Thu Sep 21 16:42:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQVNL-0004Hp-Oa; Thu, 21 Sep 2006 16:42:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQVNK-0004Hg-AG for ecrit@ietf.org; Thu, 21 Sep 2006 16:42:26 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQVNJ-0001wB-18 for ecrit@ietf.org; Thu, 21 Sep 2006 16:42:26 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.6/IER-o) with ESMTP id k8LKeEJR010871; Thu, 21 Sep 2006 15:40:14 -0500 (CDT) Received: from jrrosenberg-04.lucent.com (jrrosenberg-04.ih.lucent.com [135.185.233.167]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k8LKeJN10438; Thu, 21 Sep 2006 15:40:19 -0500 (CDT) Message-Id: <6.2.1.2.0.20060921153913.034b1750@ihmail.ih.lucent.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 21 Sep 2006 15:40:18 -0500 To: "Michael Hammer \(mhammer\)" , "Stark, Barbara" , "Henning Schulzrinne" From: John Rosenberg Subject: RE: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301F96530@xmb-rtp-20b.amer. cisco.com> References: <072C5B76F7CEAB488172C6F64B30B5E301F96530@xmb-rtp-20b.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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: , Errors-To: ecrit-bounces@ietf.org Absolutely. Different calls for different purposes, and they need to be treated differently. At 03:36 PM 9/21/2006, Michael Hammer \(mhammer\) wrote: >BTW, please keep the class of calls for (G)ETS separate from the class of >calls for 911. The government folks will get upset if the emergency >responders can't get their calls through the mass of 911 calls during >disasters. > >Mike > > > >---------- >From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] >Sent: Wednesday, September 20, 2006 10:47 AM >To: Henning Schulzrinne; John Rosenberg >Cc: Ecrit@Ietf.Org >Subject: RE: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls > >Is there an expectation that the DSCP value will change from region to region? >If not, and given that the endpoint is responsible for identifying >emergency calls, I'd rather it just be pre-configured with the correct >DSCP to use for emergency calls (SIP and RTP). >If it will different, then that will cause undesirable behavior, because >many of the network elements processing the call may not be in the same >region as the call originator and call taker. >Barbara > > >---------- >From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >Sent: Wed 9/20/2006 10:39 AM >To: John Rosenberg >Cc: Stark, Barbara; Ecrit@Ietf.Org >Subject: Re: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls > > > Anyone know of a good mechanism in SIP to tell an endpoint "use DSCP > > value 51 in your bearer packets"? > > > > This would be needed for emergency service calling, GETS/ETS (ieprep), > > and MLPP. > >This isn't really a SIP function; at best, this is the territory of SDP. > >***** > >The information transmitted is intended only for the person or entity to >which it is addressed and may contain confidential, proprietary, and/or >privileged material. Any review, retransmission, dissemination or other >use of, or taking of any action in reliance upon this information by >persons or entities other than the intended recipient is prohibited. If >you received this in error, please contact the sender and delete the >material from all computers. GA621 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 21 19:43:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQYCb-0006mj-Ke; Thu, 21 Sep 2006 19:43:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQYCa-0006md-2z for ecrit@ietf.org; Thu, 21 Sep 2006 19:43:32 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQYCV-0001Ox-Hm for ecrit@ietf.org; Thu, 21 Sep 2006 19:43:32 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail3.lucent.com (8.13.6/IER-o) with ESMTP id k8LNhEsM008987; Thu, 21 Sep 2006 18:43:14 -0500 (CDT) Received: from ILEXC1U02.ndc.lucent.com ([135.3.39.3]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Sep 2006 18:43:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls Date: Thu, 21 Sep 2006 18:43:12 -0500 Message-ID: <7D096A439A3D0D48A3D10872022CFD091B527B@ILEXC1U02.ndc.lucent.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301F96530@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls thread-index: AcbcwqHDIY9kwsWdTkKck3e2U3KnkAAACCbSAD6crcAABpO3AA== From: "GOLDMAN, STUART O \(STUART\)" To: "Michael Hammer \(mhammer\)" , "Stark, Barbara" , "Henning Schulzrinne" , "John Rosenberg" X-OriginalArrivalTime: 21 Sep 2006 23:43:13.0429 (UTC) FILETIME=[B400B450:01C6DDD7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4de5d7f989d6c039c8b887f1940f36ab 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: , Content-Type: multipart/mixed; boundary="===============0908827888==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0908827888== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6DDD7.B3DC9155" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6DDD7.B3DC9155 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Folks, =20 Would it also be correct to say that the treatment of each class would be a matter of local policy? =20 Stuart Goldman Lucent Technologies sgoldman@lucent.com 602 493 8438 =20 ________________________________ From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 Sent: Thursday, September 21, 2006 1:36 PM To: Stark, Barbara; Henning Schulzrinne; John Rosenberg Cc: Ecrit@Ietf.Org Subject: RE: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls =20 BTW, please keep the class of calls for (G)ETS separate from the class of calls for 911. The government folks will get upset if the emergency responders can't get their calls through the mass of 911 calls during disasters. =20 Mike =20 =20 =09 ________________________________ From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com]=20 Sent: Wednesday, September 20, 2006 10:47 AM To: Henning Schulzrinne; John Rosenberg Cc: Ecrit@Ietf.Org Subject: RE: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls Is there an expectation that the DSCP value will change from region to region? If not, and given that the endpoint is responsible for identifying emergency calls, I'd rather it just be pre-configured with the correct DSCP to use for emergency calls (SIP and RTP). If it will different, then that will cause undesirable behavior, because many of the network elements processing the call may not be in the same region as the call originator and call taker. Barbara =20 =09 ________________________________ From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Wed 9/20/2006 10:39 AM To: John Rosenberg Cc: Stark, Barbara; Ecrit@Ietf.Org Subject: Re: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls > Anyone know of a good mechanism in SIP to tell an endpoint "use DSCP > value 51 in your bearer packets"? > > This would be needed for emergency service calling, GETS/ETS (ieprep), > and MLPP. =09 This isn't really a SIP function; at best, this is the territory of SDP. ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621 ------_=_NextPart_001_01C6DDD7.B3DC9155 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] Identifying 911 calls and avoid congestion for 911 = calls

Folks,

 

Would = it also be correct to say that the treatment of each class would be a matter of = local policy?

 

Stuart = Goldman

Lucent = Technologies

sgoldman@lucent.com

602 493 = 8438

 

From: = Michael Hammer (mhammer) [mailto:mhammer@cisco.com]
Sent: Thursday, September = 21, 2006 1:36 PM
To: Stark, Barbara; = Henning Schulzrinne; John Rosenberg
Cc: Ecrit@Ietf.Org
Subject: RE: [Ecrit] = Identifying 911 calls and avoid congestion for 911 = calls

 

BTW, please keep the class of = calls for (G)ETS separate from the class of calls for 911.  The government = folks will get upset if the emergency responders can't get their calls = through the mass of 911 calls during disasters.

 

Mike

 

 

From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com]
Sent: Wednesday, = September 20, 2006 10:47 AM
To: Henning Schulzrinne; = John Rosenberg
Cc: Ecrit@Ietf.Org
Subject: RE: [Ecrit] = Identifying 911 calls and avoid congestion for 911 = calls

Is there an expectation that the = DSCP value will change from region to region?

If not, and given that the endpoint is responsible = for identifying emergency calls, I'd rather it just be pre-configured with = the correct DSCP to use for emergency calls (SIP and = RTP).

If it will different, then that will cause = undesirable behavior, because many of the network elements processing the call may = not be in the same region as the call originator and call = taker.

Barbara

 

From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
Sent: Wed 9/20/2006 10:39 = AM
To: John Rosenberg
Cc: Stark, Barbara; = Ecrit@Ietf.Org
Subject: Re: [Ecrit] = Identifying 911 calls and avoid congestion for 911 = calls

> Anyone know of a good mechanism in SIP to tell an endpoint "use = DSCP
> value 51 in your bearer packets"?
>
> This would be needed for emergency service calling, GETS/ETS = (ieprep),
> and MLPP.

This isn't really a SIP function; at best, this is the territory of SDP.

=

*****=

The information transmitted is intended = only for the person or entity to which it is addressed and may contain = confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon = this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and = delete the material from all computers. GA621

------_=_NextPart_001_01C6DDD7.B3DC9155-- --===============0908827888== 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 --===============0908827888==-- From ecrit-bounces@ietf.org Thu Sep 21 20:09:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQYbg-0002b7-0u; Thu, 21 Sep 2006 20:09:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQYbe-0002Wc-UH for ecrit@ietf.org; Thu, 21 Sep 2006 20:09:26 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQYbc-0005p3-6v for ecrit@ietf.org; Thu, 21 Sep 2006 20:09:26 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 21 Sep 2006 17:09:23 -0700 X-IronPort-AV: i="4.09,197,1157353200"; d="scan'208"; a="324015020:sNHT252434804" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8M09NtX021613 for ; Thu, 21 Sep 2006 17:09:23 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k8M09Nid028586 for ; Thu, 21 Sep 2006 17:09:23 -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.1830); Thu, 21 Sep 2006 17:09:22 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.121.237]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Sep 2006 17:09:22 -0700 Message-Id: <4.3.2.7.2.20060921190354.03d23f08@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Sep 2006 19:09:21 -0500 To: "Ecrit@Ietf.Org" From: "James M. Polk" Subject: RE: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls In-Reply-To: <7D096A439A3D0D48A3D10872022CFD091B527B@ILEXC1U02.ndc.lucen t.com> References: <072C5B76F7CEAB488172C6F64B30B5E301F96530@xmb-rtp-20b.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 22 Sep 2006 00:09:22.0735 (UTC) FILETIME=[5B61CBF0:01C6DDDB] DKIM-Signature: a=rsa-sha1; q=dns; l=3167; t=1158883763; x=1159747763; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:RE=3A=20[Ecrit]=20Identifying=20911=20calls=20and=20avoid=20congestion=2 0for=20911=0A=20=20calls; X=v=3Dcisco.com=3B=20h=3DhI5NNOY4MApWBvneSiWickmq8cs=3D; b=Yxsvw8Vlbcf84Gjv0Fj6TPm8gx1fo0G2ixjAE36xeZ9RXZd0U6VGPMCb2QGbfeqX+XdJMmPC EW/sto41JCgIwwTUllgJBQWyZgjA24QPt0ofTlj/kLBz60h6U49it9ro; Authentication-Results: sj-dkim-5.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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: , Errors-To: ecrit-bounces@ietf.org At 06:43 PM 9/21/2006 -0500, GOLDMAN, STUART O \(STUART\) wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C6DDD7.B3DC9155" > >Folks, > >Would it also be correct to say that the treatment of each class would be >a matter of local policy? "Local Policy" in this context is probably on a national scale, which can be quite large. Using the same indication (wherever it is) to give different treatments, separated by national boundaries, is probably fine, so long as the treatments are consistent within that boundary. >Stuart Goldman > >Lucent Technologies > >sgoldman@lucent.com > >602 493 8438 > > > >---------- >From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] >Sent: Thursday, September 21, 2006 1:36 PM >To: Stark, Barbara; Henning Schulzrinne; John Rosenberg >Cc: Ecrit@Ietf.Org >Subject: RE: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls > > > >BTW, please keep the class of calls for (G)ETS separate from the class of >calls for 911. The government folks will get upset if the emergency >responders can't get their calls through the mass of 911 calls during >disasters. > > > >Mike > > > >---------- >From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] >Sent: Wednesday, September 20, 2006 10:47 AM >To: Henning Schulzrinne; John Rosenberg >Cc: Ecrit@Ietf.Org >Subject: RE: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls >Is there an expectation that the DSCP value will change from region to >region? >If not, and given that the endpoint is responsible for identifying >emergency calls, I'd rather it just be pre-configured with the correct >DSCP to use for emergency calls (SIP and RTP). >If it will different, then that will cause undesirable behavior, because >many of the network elements processing the call may not be in the same >region as the call originator and call taker. >Barbara > >---------- >From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >Sent: Wed 9/20/2006 10:39 AM >To: John Rosenberg >Cc: Stark, Barbara; Ecrit@Ietf.Org >Subject: Re: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls > > Anyone know of a good mechanism in SIP to tell an endpoint "use DSCP > > value 51 in your bearer packets"? > > > > This would be needed for emergency service calling, GETS/ETS (ieprep), > > and MLPP. > >This isn't really a SIP function; at best, this is the territory of SDP. >***** >The information transmitted is intended only for the person or entity to >which it is addressed and may contain confidential, proprietary, and/or >privileged material. Any review, retransmission, dissemination or other >use of, or taking of any action in reliance upon this information by >persons or entities other than the intended recipient is prohibited. If >you received this in error, please contact the sender and delete the >material from all computers. GA621 >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 21 20:32:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQYxs-0005F4-0s; Thu, 21 Sep 2006 20:32:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQYxq-0005Ez-Rs for ecrit@ietf.org; Thu, 21 Sep 2006 20:32:22 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQYxn-0000iu-Cj for ecrit@ietf.org; Thu, 21 Sep 2006 20:32:22 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 21 Sep 2006 17:32:18 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8M0WIvZ002723; Thu, 21 Sep 2006 17:32:18 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k8M0WI1E023608; Thu, 21 Sep 2006 17:32:18 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Sep 2006 17:32:18 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.121.237]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Sep 2006 17:32:17 -0700 Message-Id: <4.3.2.7.2.20060921192141.02586c90@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Sep 2006 19:32:16 -0500 To: Andrew Newton , vesa-matti.hakkarainen@nokia.com From: "James M. Polk" Subject: Re: [Ecrit] Multiple sources of location information and timestamp In-Reply-To: References: <29685ED45627A84ABE58DDFC37CC3B2303529382@trebe101.NOE.Nokia.com> <29685ED45627A84ABE58DDFC37CC3B2303529382@trebe101.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 22 Sep 2006 00:32:17.0815 (UTC) FILETIME=[8EFE5A70:01C6DDDE] DKIM-Signature: a=rsa-sha1; q=dns; l=2314; t=1158885138; x=1159749138; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Ecrit]=20Multiple=20sources=20of=20location=20information=20and =0A=20=20timestamp; X=v=3Dcisco.com=3B=20h=3Dx+smInADllifv7tXqEMP785G5bY=3D; b=pNuD17Zf3pS5Go9p4AkE3gRzDQTN74XCybmhHZPdk8fxh20klarRYLTV6vNOyfFgH0yjRw1d QbnTyT9l5/Qx9aW1qzBJWs6Y/GWnSIb6kY0VjA/3uz417C6DxUAb+v/B; Authentication-Results: sj-dkim-4.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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: , Errors-To: ecrit-bounces@ietf.org At 06:50 AM 9/19/2006 -0400, Andrew Newton wrote: >On Sep 19, 2006, at 6:02 AM, >vesa-matti.hakkarainen@nokia.com >wrote: > >>Hi all, >> >>UE may include multiple location objects into emergency session INVITE. >>To my knowledge it has not been defined how to select which one of the >>location objects is used for routing to PSAP if the location objects lead >>to different PSAPs. I think timestamp when the location objects were >>created could be useful in selecting the most recent location information >>but PIDF defines timestamp only for the whole presence tuple. Has this >>been discussed and does anybody see this as a problmem? Or is there some >>way to identify the time when the location object was created? >> >>Br, >> Vesa Hakkarainen > >We've been round and round on the discussion about what to feed the >routing function (LoST). Until now, we have assumed it is the location >being conveyed to the PSAP. But there seems to be a problem. If the >input to the routing function is complex, the results are >undesirable. Yet, there seems to be a desire to have the PSAPs get these >very complex shapes. > >Perhaps there should be two sets of location info, each clearly marked: >one for routing, one for the PSAPs. SIP does not mandate support for multipart message bodies (which is a problem for an SDP and PIDF-LO message body), but now you are suggesting 3 message bodies in an INVITE? Also, SIP allows UDP, and several vendors have not implemented TCP (despite it being mandatory per 3261). If there are now 2 message bodies containing location, there would be a growing problem (literally) of messages being or becoming too large to get to the destination because some middle SIP intermediary doesn't support TCP. Please don't say it won't happen, as it already has to us with a partner vendor (and that's before we included a large location body or two) > I'd also suggest giving the PSAPs the input to the routing function as > well, but clearly marking the purpose of the information could help solve > this problem. > >-andy >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 21 20:44:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQZ9K-0002Kt-Lj; Thu, 21 Sep 2006 20:44:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQZ9I-0002Ko-KR for ecrit@ietf.org; Thu, 21 Sep 2006 20:44:12 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQZ9H-0002XS-DI for ecrit@ietf.org; Thu, 21 Sep 2006 20:44:12 -0400 Received: from [10.0.1.52] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Thu, 21 Sep 2006 20:43:36 -0400 id 01588353.451331B8.000072E6 In-Reply-To: <4.3.2.7.2.20060921192141.02586c90@email.cisco.com> References: <29685ED45627A84ABE58DDFC37CC3B2303529382@trebe101.NOE.Nokia.com> <29685ED45627A84ABE58DDFC37CC3B2303529382@trebe101.NOE.Nokia.com> <4.3.2.7.2.20060921192141.02586c90@email.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <50E4ADC3-5563-4798-AF4C-8A1DCB84EEE2@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Multiple sources of location information and timestamp Date: Thu, 21 Sep 2006 20:43:42 -0400 To: "James M. Polk" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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: , Errors-To: ecrit-bounces@ietf.org On Sep 21, 2006, at 8:32 PM, James M. Polk wrote: > SIP does not mandate support for multipart message bodies (which is > a problem for an SDP and PIDF-LO message body), but now you are > suggesting 3 message bodies in an INVITE? Actually, I was thinking more of multiple locations within PIDF-LO, each marked as to its purpose. > Also, SIP allows UDP, and several vendors have not implemented TCP > (despite it being mandatory per 3261). If there are now 2 message > bodies containing location, there would be a growing problem > (literally) of messages being or becoming too large to get to the > destination because some middle SIP intermediary doesn't support TCP. > > Please don't say it won't happen, as it already has to us with a > partner vendor (and that's before we included a large location body > or two) TCP vs. UDP is a battle for another day. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 21 20:53:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQZIJ-00063m-DX; Thu, 21 Sep 2006 20:53:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQZII-00063h-FV for ecrit@ietf.org; Thu, 21 Sep 2006 20:53:30 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQZIH-00045S-Ub for ecrit@ietf.org; Thu, 21 Sep 2006 20:53:30 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Sep 2006 19:53:27 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 21 Sep 2006 19:53:27 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Sep 2006 19:53:26 -0500 Message-ID: From: "Winterbottom, James" To: "Andrew Newton" , Date: Thu, 21 Sep 2006 19:53:24 -0500 Subject: RE: [Ecrit] Multiple sources of location information and timestamp MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 22 Sep 2006 00:53:26.0683 (UTC) FILETIME=[834C3EB0:01C6DDE1] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Multiple sources of location information and timestamp Thread-Index: Acbb2ZbZC9tS/+1LSJG432pnifY2QACBig4w X-Spam-Score: 0.1 (/) X-Scan-Signature: 562cdc9baa87554b29d950396a30cf75 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: , Content-Type: multipart/mixed; boundary="===============1426287656==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1426287656== Content-Type: multipart/alternative; boundary="--=_NextPart_ST_19_53_27_Thursday_September_21_2006_26323" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ----=_NextPart_ST_19_53_27_Thursday_September_21_2006_26323 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andy, =20 PSAPs in the USA today for cellular can only receive a point, point with uncertainty circle, point with altitude, or point with altitude an uncertainty radius.=20 These translate to 2D point, 3D point, circle and sphere as were defined in the GeoShapes draft. This restriction comes about because of what can be provided over the E2 interface between the MPC/GMLC and the ALI. =20 In the UK and Europe shape types are not so restricted as they use the OMA MLP specification. That is, they can receive any of the shape types defined in the geoshape draft with the exception of the Prism. So your point that these are complexity of these shapes is a little unfounded given that they can be received today. =20 Further, one of the purposes of the LIS in the NENA architecture is to ensure that locations provided to end-points for are in a suitable form to be digested by the local PSAP, and hence should also be able to yield a valid route to the local PSAP. To that end, the PSAPs already have the say in route determination you described below. =20 Cheers James =20 =20 ________________________________ From: Andrew Newton [mailto:andy@hxr.us]=20 Sent: Tuesday, 19 September 2006 8:50 PM To: vesa-matti.hakkarainen@nokia.com Cc: ecrit@ietf.org Subject: Re: [Ecrit] Multiple sources of location information and timestamp =20 =20 On Sep 19, 2006, at 6:02 AM, vesa-matti.hakkarainen@nokia.com wrote: Hi all,=20 UE may include multiple location objects into emergency session INVITE. To my knowledge it has not been defined how to select which one of the location objects is used for routing to PSAP if the location objects lead to different PSAPs. I think timestamp when the location objects were created could be useful in selecting the most recent location information but PIDF defines timestamp only for the whole presence tuple. Has this been discussed and does anybody see this as a problmem? Or is there some way to identify the time when the location object was created? Br,=20 Vesa Hakkarainen=20 =20 We've been round and round on the discussion about what to feed the routing function (LoST). Until now, we have assumed it is the location being conveyed to the PSAP. But there seems to be a problem. If the input to the routing function is complex, the results are undesirable. Yet, there seems to be a desire to have the PSAPs get these very complex shapes. =20 Perhaps there should be two sets of location info, each clearly marked: one for routing, one for the PSAPs. I'd also suggest giving the PSAPs the input to the routing function as well, but clearly marking the purpose of the information could help solve this problem. =20 -andy ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] ----=_NextPart_ST_19_53_27_Thursday_September_21_2006_26323 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Andy,

 

PSAPs in the USA today for cellular can on= ly receive a point, point with uncertainty circle, point with altitude, or poi= nt with altitude an uncertainty radius.

These translate to 2D point, 3D point, circle and sphere as were defined in the GeoShapes draft. This restriction comes about because of what can be provided over the E2 interface between t= he MPC/GMLC and the ALI.

 

In the UK and Europe shape types are not so restri= cted as they use the OMA MLP specification. That is, they can receive any of the shape types defined in the geoshape draft with the exception of the Prism. =  So your point that these are complexity of these shapes is a little unfounded given that they can be received today.

 

Further, one of the purposes of the LI= S in the NENA architecture is to ensure that locations provided to end-points fo= r are in a suitable form to be digested by the local PSAP, and hence should also = be able to yield a valid route  to the local PSAP. To that end, the PSAPs already have the say in route determination you described below.=

 

Cheers

James

 

 

From:= Andrew Newton [mailto:andy@hxr.us]
Sent: Tuesday, 19 September = 2006 8:50 PM
To: vesa-matti.hakkarainen@nokia.com
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] Multipl= e sources of location information and timestamp

 

 

On Sep 19, 2006, at 6:02 AM, vesa-matti.hakkarainen@nok= ia.com wrote:



Hi all,

UE may include multiple location objects into emergency session INVITE. To my knowledge it has not been defined how to select which one of the location objects is used for routing to PSAP if the location objects lead to differe= nt PSAPs. I think timestamp when the location objects were created could be us= eful in selecting the most recent location information but PIDF defines timestam= p only for the whole presence tuple. Has this been discussed and does anybody= see this as a problmem? Or is there some way to identify the time when the loca= tion object was created?

Br,
        Vesa Hakkarainen=

 

We've been round and round on the discussion about what to feed the routing function (LoST).  Until now, we have assumed it is the locatio= n being conveyed to the PSAP.  But there seems to be a problem.  If= the input to the routing function is complex, the results are undesirable. = ; Yet, there seems to be a desire to have the PSAPs get these very complex shapes.

 

Perhaps there should be two sets of location info, each clearly mar= ked: one for routing, one for the PSAPs.  I'd also suggest giving the PSAPs= the input to the routing function as well, but clearly marking the purpose of t= he information could help solve this problem.

 

-andy


-----------------------------------------------------------------------= -------------------------
This message is for the designated recipient o= nly and may
contain privileged, proprietary, or otherwise private inform= ation.
If you have received it in error, please notify the sender
i= mmediately and delete the original. Any unauthorized use of
this email = is prohibited.
---------------------------------------------------------= ---------------------------------------
[mf2] ----=_NextPart_ST_19_53_27_Thursday_September_21_2006_26323-- --===============1426287656== 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 --===============1426287656==-- From ecrit-bounces@ietf.org Thu Sep 21 21:18:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQZg3-0001Mo-TC; Thu, 21 Sep 2006 21:18:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQZg2-0001Mj-CO for ecrit@ietf.org; Thu, 21 Sep 2006 21:18:02 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQZg1-00018W-1U for ecrit@ietf.org; Thu, 21 Sep 2006 21:18:02 -0400 Received: from [10.0.1.52] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Thu, 21 Sep 2006 21:17:48 -0400 id 01588176.451339BD.0000787F In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0310E226-4003-4526-BD97-02DDFF3A543C@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Multiple sources of location information and timestamp Date: Thu, 21 Sep 2006 21:17:59 -0400 To: "Winterbottom, James" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Sep 21, 2006, at 8:53 PM, Winterbottom, James wrote: > PSAPs in the USA today for cellular can only receive a point, point > with uncertainty circle, point with altitude, or point with > altitude an uncertainty radius. > > These translate to 2D point, 3D point, circle and sphere as were > defined in the GeoShapes draft. This restriction comes about > because of what can be provided over the E2 interface between the > MPC/GMLC and the ALI. > > > > In the UK and Europe shape types are not so restricted as they use > the OMA MLP specification. That is, they can receive any of the > shape types defined in the geoshape draft with the exception of the > Prism. So your point that these are complexity of these shapes is > a little unfounded given that they can be received today. At what point was I suggesting the PSAPs should not receive these complex shapes? > Further, one of the purposes of the LIS in the NENA architecture is > to ensure that locations provided to end-points for are in a > suitable form to be digested by the local PSAP, and hence should > also be able to yield a valid route to the local PSAP. To that > end, the PSAPs already have the say in route determination you > described below. With all due respect, we are not talking about a NENA architecture. We are talking about an ECRIT architecture. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 21 21:28:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQZqJ-0005sl-R5; Thu, 21 Sep 2006 21:28:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQZqI-0005sg-UO for ecrit@ietf.org; Thu, 21 Sep 2006 21:28:38 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQZqH-0004bJ-Mu for ecrit@ietf.org; Thu, 21 Sep 2006 21:28:38 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Sep 2006 20:28:37 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 21 Sep 2006 20:28:37 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Sep 2006 20:28:36 -0500 Message-ID: From: "Winterbottom, James" To: "Andrew Newton" Date: Thu, 21 Sep 2006 20:28:35 -0500 Subject: RE: [Ecrit] Multiple sources of location information and timestamp MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 22 Sep 2006 01:28:36.0632 (UTC) FILETIME=[6CECE980:01C6DDE6] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <0310E226-4003-4526-BD97-02DDFF3A543C@hxr.us> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Multiple sources of location information and timestamp Thread-Index: Acbd5PLJoCsr92SkT8GbcCBeHWCThwAACr8g X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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: , Errors-To: ecrit-bounces@ietf.org > At what point was I suggesting the PSAPs should not receive these > complex shapes? I seem to have misread your comment, my apologies. >=20 > > Further, one of the purposes of the LIS in the NENA architecture is > > to ensure that locations provided to end-points for are in a > > suitable form to be digested by the local PSAP, and hence should > > also be able to yield a valid route to the local PSAP. To that > > end, the PSAPs already have the say in route determination you > > described below. >=20 > With all due respect, we are not talking about a NENA architecture. > We are talking about an ECRIT architecture. To the best of my knowledge, ECRIT does not specify how an end-point or call-server for that matter should learn location information. It does however concern itself with the provisioning and querying of PSAP and other service boundaries. To bury our heads in the sand and ignore what other organizations have already architected and are implementing in this direction is tantamount to developing a square wheel because we don't like the people that were offering us a round one.=20 This should not be an NIH debate, but one that actually involves the organizations that are delivering these services today and helping them to evolve towards a strong safe NG architecture. Ignoring what they have done does not breed that cooperation. >=20 > -andy ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 21 23:08:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQbOs-0003ri-Nq; Thu, 21 Sep 2006 23:08:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQbOr-0003rd-Ev for ecrit@ietf.org; Thu, 21 Sep 2006 23:08:25 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQbOq-0005a7-45 for ecrit@ietf.org; Thu, 21 Sep 2006 23:08:25 -0400 Received: from dynamic-acs-24-154-127-115.zoominternet.net ([24.154.127.115] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GQbMj-0003GO-IT; Thu, 21 Sep 2006 22:06:39 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'ECRIT'" Subject: RE: [Ecrit] Mapping Architecture Question Date: Thu, 21 Sep 2006 23:07:52 -0400 Message-ID: <057101c6ddf4$5c0ad3d0$7e0210ac@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <45123A34.9080301@gmx.net> Thread-Index: AcbdTHI1vtuJDjGjS2urTCMg3VlbDAAZYp8w X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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: , Errors-To: ecrit-bounces@ietf.org I write this at an airport without Internet connectivity and before I see what Henning has in mind. What I believed was that the FGs discovered each other, they were not configured. I could understand some kind of a boot process which had some configuration data, but I thought the idea was that it was more or less a free for all in FGs, which meant there was a possibility of two FGs giving conflicting information on the resolvers. I did expect the resolver to be configured with at least one FG to get started. Brian > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Thursday, September 21, 2006 3:08 AM > To: ECRIT > Subject: [Ecrit] Mapping Architecture Question > > Hi all, > > consider the following picture from draft-ietf-ecrit-mapping-arch-00.txt: > > > /-\ /-\ +-----+ +-----+ > | S +******* R ********* FG *-----------------+ FG | > \-/ \-/ | |* | | > +--+--+ * +--+--+ > | * | > | * | > | * | > | * | > /-\ +--+--+ * +--+--+ > | R +------>+ FG +-----*-----------+ FG | > \-/ | | * | | > +--+--+ * +--+--+ > | * | > | * | > | * | > |*** ^ > / \ / \ > / \ / \ > / \ / \ > / \ / \ > ----------- ----------- > tree tree > > What does each entity need to know? > > * Seeker: It only needs to be configured with a resolver (=LoST server). > See DHCP and DNS-based mechanism (i.e., a dynamic discovery mechanism). > > * Resolver: It needs to be configured with the FG address, i.e., it > needs to know at least one FG. Ideally, it knows which FG is responsible > for which region. In this case it might just contact the right FG > without contacting FGs. Additionally, the resolver might also know some > other LoST servers within its tree to speed-up search. > > I assume that the addresses of FGs and LoST servers a resolver knows is > largely based on manual configuration? > > The resolver will also cache service boundaries to speed up future > search attempts. > > * Forest Guide: The FGs need to be aware of each other. This is most > likely be based on manual configuration. For example, the FG is manually > configured with the address of the FG in Germany. The FG also needs to > know the service boundaries of each FG. This might also be exchanged out > of band. > > Are my observations largely correct? > > Ciao > Hannes > > PS: The term 'tree' is a bit misleading since it collectively refers to > the LoST server below a FG. The figure only shows resolves that are part > of this tree but does not depict authoritative LoST servers. > > _______________________________________________ > 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 Sep 22 03:51:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQfog-0006TX-Me; Fri, 22 Sep 2006 03:51:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQfof-0006TS-WA for ecrit@ietf.org; Fri, 22 Sep 2006 03:51:22 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GQfob-0005HQ-IP for ecrit@ietf.org; Fri, 22 Sep 2006 03:51:21 -0400 Received: (qmail invoked by alias); 22 Sep 2006 07:51:16 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp039) with SMTP; 22 Sep 2006 09:51:16 +0200 X-Authenticated: #29516787 Message-ID: <451395FD.9030103@gmx.net> Date: Fri, 22 Sep 2006 03:51:25 -0400 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] Hum for draft-polk-ecrit-dhc-lost-discovery-00.txt References: <000001c6db7c$03db01f0$1152150a@amer.cisco.com> <45102B8C.5080803@gmx.net> <45102D53.5020205@gmx.net> <45114C31.1060901@hxr.us> In-Reply-To: <45114C31.1060901@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.6 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Leslie Daigle , "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: , Errors-To: ecrit-bounces@ietf.org Hi Andy, Andrew Newton schrieb: > Hannes Tschofenig wrote: >> We used the procedure used in RFC 3361 and from RFC 3319. >> >> RFC 3361 >> Dynamic Host Configuration Protocol (DHCP-for-IPv4) >> Option for Session Initiation Protocol (SIP) Servers >> >> RFC 3319 >> >> Dynamic Host Configuration Protocol (DHCPv6) Options >> for Session Initiation Protocol (SIP) Servers > > Yes, it looks very similar. But the usages for SIP and LoST are very > different. SIP and LoST are very different. The discovery mechanism is, however, similar. The problem is that your LoST location configuration with > DHCP is actually non-interoperable with the current LoST specification. > > dhc-lost-discovery describes three methods of configuration: > > 1) IP address(es). > 2) A record lookup. > 3) Multiple NAPTR record lookups. > > The problem with the 1 and 2 is that they don't do enough. The U-NAPTR > resolution specified in LoST could, and likely should, result in HTTP > URIs that use ports other than 80 with specific query paths. Why do you think that it is useful to use anything other than the default port with U-NAPTR for LoST discovery? I would argue that this would make it very hard to get the LoST messages through a firewall. Imaging, I a LoST server at my VSP running at a port number that is provided by U-NAPTR. Do you think I would get through most firewalls in access networks? As an > example: https://example.com:4433/lost/. Neither an IP address nor an A > record is enough information to construct that URI. While I agree that these discovery mechanisms provide different properties it is up to the local network to determine what they would like to use. If there is only a single LoST server in the access network running at port 80 why do we need to use anything else than (1). > > The problem with option 3 is that it fails to understand how DNS and > U-NAPTR work. Your specification says that when multiple DNS qnames are > present, they are used to query multiple NAPTR records. Why? The query > against one qname can result in multiple NAPTR records. What's the > purpose of adding a layer above the U-NAPTR algorithm? The DHCP-based mechanism is not there to replace or compete in any way with the mechanism proposed in the LoST draft. They just fulfill an entirely different purpose. It would be fine for me to just specify a single FQDN in the DHCP option if that would satisfy some of your concerns. > I can only conclude that this draft is incompatible with the work > already accepted by ECRIT, and therefore should not be accepted as a > working group item until it is fixed. > > To be quite clear, I like the idea of using DHCP to configure a pointer > to the LoST server, and I'd be in favor of working group acceptance of a > document that did it in a way compatible with LoST. Ciao Hannes > > -andy > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 22 03:57:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQfu2-0000E6-8a; Fri, 22 Sep 2006 03:56:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQfu0-0000E1-OX for ecrit@ietf.org; Fri, 22 Sep 2006 03:56:52 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GQftz-0005j3-B1 for ecrit@ietf.org; Fri, 22 Sep 2006 03:56:52 -0400 Received: (qmail invoked by alias); 22 Sep 2006 07:56:50 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp029) with SMTP; 22 Sep 2006 09:56:50 +0200 X-Authenticated: #29516787 Message-ID: <4513974A.1000504@gmx.net> Date: Fri, 22 Sep 2006 03:56:58 -0400 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Leslie Daigle Subject: Re: [Ecrit] Hum for draft-polk-ecrit-dhc-lost-discovery-00.txt References: <000001c6db7c$03db01f0$1152150a@amer.cisco.com> <45102B8C.5080803@gmx.net> <45102D53.5020205@gmx.net> <45114C31.1060901@hxr.us> <4511C03D.9040100@thinkingcat.com> In-Reply-To: <4511C03D.9040100@thinkingcat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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: , Errors-To: ecrit-bounces@ietf.org Hi Leslie, I just to make sure that I understand you right. With the third option you would use the DHCP option to return an FQDN (instead of a domain name) and use it as input to the U-NAPTR-based discovery found in the LoST specification. I am just curious why the mechanisms used for SIP are not good enough for our purpose. Ciao Hannes Leslie Daigle schrieb: > > Further -- as noted in all the DDDS documentation, NAPTR > records don't exist "in the wild"; they are always part of a > DDDS application (in this case, U-NAPTR). > > So -- it seems that the 3rd option should really be about > specifying the application unique string that feeds into > the U-NAPTR-based LoST discovery specification. The > application unique string would, in fact, be an FQDN. > > If you really need another layer of indirection (and I suspect > Andy is right, you don't), you could still have multiple > AUS's. > > Leslie. > > Andrew Newton wrote: >> Hannes Tschofenig wrote: >>> We used the procedure used in RFC 3361 and from RFC 3319. >>> >>> RFC 3361 >>> Dynamic Host Configuration Protocol (DHCP-for-IPv4) >>> Option for Session Initiation Protocol (SIP) Servers >>> >>> RFC 3319 >>> >>> Dynamic Host Configuration Protocol (DHCPv6) Options >>> for Session Initiation Protocol (SIP) Servers >> >> Yes, it looks very similar. But the usages for SIP and LoST are very >> different. The problem is that your LoST location configuration with >> DHCP is actually non-interoperable with the current LoST specification. >> >> dhc-lost-discovery describes three methods of configuration: >> >> 1) IP address(es). >> 2) A record lookup. >> 3) Multiple NAPTR record lookups. >> >> The problem with the 1 and 2 is that they don't do enough. The >> U-NAPTR resolution specified in LoST could, and likely should, result >> in HTTP URIs that use ports other than 80 with specific query paths. >> As an example: https://example.com:4433/lost/. Neither an IP address >> nor an A record is enough information to construct that URI. >> >> The problem with option 3 is that it fails to understand how DNS and >> U-NAPTR work. Your specification says that when multiple DNS qnames >> are present, they are used to query multiple NAPTR records. Why? The >> query against one qname can result in multiple NAPTR records. What's >> the purpose of adding a layer above the U-NAPTR algorithm? >> >> I can only conclude that this draft is incompatible with the work >> already accepted by ECRIT, and therefore should not be accepted as a >> working group item until it is fixed. >> >> To be quite clear, I like the idea of using DHCP to configure a >> pointer to the LoST server, and I'd be in favor of working group >> acceptance of a document that did it in a way compatible with LoST. >> >> -andy >> > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 22 10:32:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQm4p-0007RB-Ue; Fri, 22 Sep 2006 10:32:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQm4p-0007R6-7h for ecrit@ietf.org; Fri, 22 Sep 2006 10:32:27 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQm4o-0001bc-2A for ecrit@ietf.org; Fri, 22 Sep 2006 10:32:27 -0400 Received: from [172.16.10.86] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Fri, 22 Sep 2006 10:32:01 -0400 id 0158841E.4513F3E1.0000159C Message-ID: <4513F3E2.4090000@hxr.us> Date: Fri, 22 Sep 2006 10:32:02 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] Hum for draft-polk-ecrit-dhc-lost-discovery-00.txt References: <000001c6db7c$03db01f0$1152150a@amer.cisco.com> <45102B8C.5080803@gmx.net> <45102D53.5020205@gmx.net> <45114C31.1060901@hxr.us> <451395FD.9030103@gmx.net> In-Reply-To: <451395FD.9030103@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Leslie Daigle , "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: , Errors-To: ecrit-bounces@ietf.org Hannes Tschofenig wrote: [...skipping dangerous assumptions about port 80...] > It would be fine for me to just specify a single FQDN in the DHCP option > if that would satisfy some of your concerns. Yes, it would. And that would be simpler to code against, too. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 22 10:34:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQm6v-0000Ao-15; Fri, 22 Sep 2006 10:34:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQm6t-0000Ah-0J for ecrit@ietf.org; Fri, 22 Sep 2006 10:34:35 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQm6r-00026o-QT for ecrit@ietf.org; Fri, 22 Sep 2006 10:34:34 -0400 Received: from [172.16.10.86] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Fri, 22 Sep 2006 10:34:21 -0400 id 0158841E.4513F46D.0000166D Message-ID: <4513F46D.30008@hxr.us> Date: Fri, 22 Sep 2006 10:34:21 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] Hum for draft-polk-ecrit-dhc-lost-discovery-00.txt References: <000001c6db7c$03db01f0$1152150a@amer.cisco.com> <45102B8C.5080803@gmx.net> <45102D53.5020205@gmx.net> <45114C31.1060901@hxr.us> <4511C03D.9040100@thinkingcat.com> <4513974A.1000504@gmx.net> In-Reply-To: <4513974A.1000504@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Leslie Daigle , "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: , Errors-To: ecrit-bounces@ietf.org Hannes Tschofenig wrote: > I just to make sure that I understand you right. With the third option > you would use the DHCP option to return an FQDN (instead of a domain > name) and use it as input to the U-NAPTR-based discovery found in the > LoST specification. Oh boy! What's the difference between a FQDN and a domain name? > I am just curious why the mechanisms used for SIP are not good enough > for our purpose. I think the better question is, why do we need to copy the mechanisms from SIP when there is a simpler solution? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 22 10:57:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQmSZ-0001le-Eu; Fri, 22 Sep 2006 10:56:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQmSX-0001l7-QR for ecrit@ietf.org; Fri, 22 Sep 2006 10:56:58 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQmSS-00074E-Lx for ecrit@ietf.org; Fri, 22 Sep 2006 10:56:57 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k8MEuhg0027769; Fri, 22 Sep 2006 16:56:43 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k8MEugUN023836; Fri, 22 Sep 2006 16:56:42 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Sep 2006 16:56:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] Hum for draft-polk-ecrit-dhc-lost-discovery-00.txt Date: Fri, 22 Sep 2006 16:56:06 +0200 Message-ID: In-Reply-To: <4513F46D.30008@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Hum for draft-polk-ecrit-dhc-lost-discovery-00.txt Thread-Index: AcbeVGap4zTqu+DLR8+2cTGGJSQPdAAAQM/A From: "Tschofenig, Hannes" To: "Andrew Newton" , "Hannes Tschofenig" X-OriginalArrivalTime: 22 Sep 2006 14:56:42.0525 (UTC) FILETIME=[50C50CD0:01C6DE57] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Leslie Daigle , "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: , Errors-To: ecrit-bounces@ietf.org Hi Andy,=20 > Hannes Tschofenig wrote: > > I just to make sure that I understand you right. With the=20 > third option=20 > > you would use the DHCP option to return an FQDN (instead of=20 > a domain=20 > > name) and use it as input to the U-NAPTR-based discovery=20 > found in the=20 > > LoST specification. >=20 > Oh boy! What's the difference between a FQDN and a domain name? Sorry. It should read 'return an FQDN (instead of an IP address)'. >=20 > > I am just curious why the mechanisms used for SIP are not=20 > good enough=20 > > for our purpose. >=20 > I think the better question is, why do we need to copy the=20 > mechanisms from=20 > SIP when there is a simpler solution? It might look nicer but it less efficient with regard to the number of messages that are needed before we get the IP address of the LoST server. =20 How many LoST servers do we think we typically have in an access network?=20 Ciao Hannes >=20 > -andy >=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 Sep 22 11:08:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQme1-0006be-OO; Fri, 22 Sep 2006 11:08:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQme0-0006bZ-8g for ecrit@ietf.org; Fri, 22 Sep 2006 11:08:48 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQmdz-0007vg-2d for ecrit@ietf.org; Fri, 22 Sep 2006 11:08:48 -0400 Received: from [172.16.10.86] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Fri, 22 Sep 2006 11:08:34 -0400 id 0158841E.4513FC72.00001E3F Message-ID: <4513FC6E.40100@hxr.us> Date: Fri, 22 Sep 2006 11:08:30 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "Tschofenig, Hannes" Subject: Re: AW: [Ecrit] Hum for draft-polk-ecrit-dhc-lost-discovery-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Leslie Daigle , "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: , Errors-To: ecrit-bounces@ietf.org Tschofenig, Hannes wrote: > It might look nicer but it less efficient with regard to the number of > messages that are needed before we get the IP address of the LoST > server. I'm afraid the number of messages argument has been lost on LoST... I should know, I was the one making it. If we are truly concerned about the number of messages, then we should seriously think about dropping HTTP and HTTPS in favor of a UDP transfer service. But we are not doing that because in general there does not seem to be a large concern about this. Do you really want to open that can of worms? Additionally, this is a configuration-time or network-attachment-time process, and the engineering in this working group regarding processes that take place at network attachment have always assumed plenty of breathing room. We can also re-examine that if you would like, but I don't recommend it. Finally, I can't help but point out that the 3rd mechanism in the current draft is a layer on top of U-NAPTR, and therefore even more messages than the concern you have stated. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 22 11:09:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQmem-0007x2-5G; Fri, 22 Sep 2006 11:09:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQmel-0007sT-9a for ecrit@ietf.org; Fri, 22 Sep 2006 11:09:35 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GQmei-0007y5-Nf for ecrit@ietf.org; Fri, 22 Sep 2006 11:09:35 -0400 Received: (qmail invoked by alias); 22 Sep 2006 15:09:29 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp035) with SMTP; 22 Sep 2006 17:09:29 +0200 X-Authenticated: #29516787 Message-ID: <4513FCAD.4020101@gmx.net> Date: Fri, 22 Sep 2006 11:09:33 -0400 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] Hum for draft-polk-ecrit-dhc-lost-discovery-00.txt References: <000001c6db7c$03db01f0$1152150a@amer.cisco.com> <45102B8C.5080803@gmx.net> <45102D53.5020205@gmx.net> <45114C31.1060901@hxr.us> <451395FD.9030103@gmx.net> <4513F3E2.4090000@hxr.us> In-Reply-To: <4513F3E2.4090000@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Leslie Daigle , "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: , Errors-To: ecrit-bounces@ietf.org Hi Andy, Andrew Newton schrieb: > Hannes Tschofenig wrote: > > [...skipping dangerous assumptions about port 80...] You seem to assume that we have to return a port number as part of the discovery procedure, I guess. > >> It would be fine for me to just specify a single FQDN in the DHCP >> option if that would satisfy some of your concerns. > > Yes, it would. And that would be simpler to code against, too. Is it OK for you to still have the ability to carry an IP address to the end host using DHCP in there? Ciao Hannes > > -andy > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 22 11:14:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQmj6-0000bz-4X; Fri, 22 Sep 2006 11:14:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQmj4-0000bn-TP for ecrit@ietf.org; Fri, 22 Sep 2006 11:14:02 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQmiz-0008SO-LE for ecrit@ietf.org; Fri, 22 Sep 2006 11:14:02 -0400 Received: from [172.16.10.86] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Fri, 22 Sep 2006 11:13:45 -0400 id 01588423.4513FDA9.00001F69 Message-ID: <4513FDA9.7000707@hxr.us> Date: Fri, 22 Sep 2006 11:13:45 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] Hum for draft-polk-ecrit-dhc-lost-discovery-00.txt References: <000001c6db7c$03db01f0$1152150a@amer.cisco.com> <45102B8C.5080803@gmx.net> <45102D53.5020205@gmx.net> <45114C31.1060901@hxr.us> <451395FD.9030103@gmx.net> <4513F3E2.4090000@hxr.us> <4513FCAD.4020101@gmx.net> In-Reply-To: <4513FCAD.4020101@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Leslie Daigle , "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: , Errors-To: ecrit-bounces@ietf.org Hannes Tschofenig wrote: > You seem to assume that we have to return a port number as part of the > discovery procedure, I guess. Not just a port number, but an HTTP query path too. Please go back and read my email about how you get from an IP address to a URI. > Is it OK for you to still have the ability to carry an IP address to the > end host using DHCP in there? Absolutely not. Again, an IP address does not contain enough information to construct an HTTP URI. See above. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Sep 23 06:09:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GR4RN-0007QK-Ju; Sat, 23 Sep 2006 06:08:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GR4RM-0007QF-UP for ecrit@ietf.org; Sat, 23 Sep 2006 06:08:56 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GR4RL-0007Ak-NT for ecrit@ietf.org; Sat, 23 Sep 2006 06:08:56 -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 k8NA8jGb014657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 23 Sep 2006 06:08:46 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id k8NA8gCA003935; Sat, 23 Sep 2006 06:08:44 -0400 Message-ID: <451507AA.20407@cs.columbia.edu> Date: Sat, 23 Sep 2006 12:08:42 +0200 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] Hum for draft-polk-ecrit-dhc-lost-discovery-00.txt References: <000001c6db7c$03db01f0$1152150a@amer.cisco.com> <45102B8C.5080803@gmx.net> <45102D53.5020205@gmx.net> <45114C31.1060901@hxr.us> <451395FD.9030103@gmx.net> <4513F3E2.4090000@hxr.us> <4513FCAD.4020101@gmx.net> <4513FDA9.7000707@hxr.us> In-Reply-To: <4513FDA9.7000707@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter2.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Leslie Daigle , "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: , Errors-To: ecrit-bounces@ietf.org Andrew Newton wrote: > Hannes Tschofenig wrote: >> You seem to assume that we have to return a port number as part of the >> discovery procedure, I guess. > > Not just a port number, but an HTTP query path too. Please go back and > read my email about how you get from an IP address to a URI. Not really. The LoST-URL U-NAPTR process does this already. There's no need to do this twice. > >> Is it OK for you to still have the ability to carry an IP address to >> the end host using DHCP in there? > > Absolutely not. Again, an IP address does not contain enough > information to construct an HTTP URI. See above. > > -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 Sat Sep 23 10:28:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GR8Tm-0006vQ-Fa; Sat, 23 Sep 2006 10:27:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GR8Tk-0006nj-CO for ecrit@ietf.org; Sat, 23 Sep 2006 10:27:40 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GR8Tj-0000ep-5i for ecrit@ietf.org; Sat, 23 Sep 2006 10:27:40 -0400 Received: from [10.0.1.52] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Sat, 23 Sep 2006 10:27:14 -0400 id 01588420.45154442.00000D6B In-Reply-To: <451507AA.20407@cs.columbia.edu> References: <000001c6db7c$03db01f0$1152150a@amer.cisco.com> <45102B8C.5080803@gmx.net> <45102D53.5020205@gmx.net> <45114C31.1060901@hxr.us> <451395FD.9030103@gmx.net> <4513F3E2.4090000@hxr.us> <4513FCAD.4020101@gmx.net> <4513FDA9.7000707@hxr.us> <451507AA.20407@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <144F8FBA-AC7D-4ACB-9A4E-D2FD809C55E7@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Hum for draft-polk-ecrit-dhc-lost-discovery-00.txt Date: Sat, 23 Sep 2006 10:27:25 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Leslie Daigle , "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: , Errors-To: ecrit-bounces@ietf.org On Sep 23, 2006, at 6:08 AM, Henning Schulzrinne wrote: > > > Andrew Newton wrote: >> Hannes Tschofenig wrote: >>> You seem to assume that we have to return a port number as part >>> of the discovery procedure, I guess. >> Not just a port number, but an HTTP query path too. Please go >> back and read my email about how you get from an IP address to a URI. > > Not really. The LoST-URL U-NAPTR process does this already. There's > no need to do this twice. That would be great, except we are talking about an IP address and not a LoST URL. Besides, the LoST URL produces an HTTP URL from the U-NAPTR process, and that is where you get a query path. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Sep 24 20:12:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRe4z-0000Wb-A9; Sun, 24 Sep 2006 20:12:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRe4y-0000WV-5a for ecrit@ietf.org; Sun, 24 Sep 2006 20:12:12 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRe4w-0004YM-Rw for ecrit@ietf.org; Sun, 24 Sep 2006 20:12:12 -0400 Received: from [192.168.0.41] (pool-141-153-175-20.mad.east.verizon.net [141.153.175.20]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k8P0C1u9000280 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sun, 24 Sep 2006 20:12:06 -0400 (EDT) In-Reply-To: <45123A34.9080301@gmx.net> References: <45123A34.9080301@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <73222BD7-09C8-4758-BA43-6191AFC70F42@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Mapping Architecture Question Date: Sun, 24 Sep 2006 20:11:54 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-PerlMx-Spam: Gauge=XXII, Probability=22%, X-Seen-By filter1.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Please see below: On Sep 21, 2006, at 3:07 AM, Hannes Tschofenig wrote: > Hi all, > > consider the following picture from draft-ietf-ecrit-mapping- > arch-00.txt: > > > /-\ /-\ +-----+ +-----+ > | S +******* R ********* FG *-----------------+ FG | > \-/ \-/ | |* | | > +--+--+ * +--+--+ > | * | > | * | > | * | > | * | > /-\ +--+--+ * +--+--+ > | R +------>+ FG +-----*-----------+ FG | > \-/ | | * | | > +--+--+ * +--+--+ > | * | > | * | > | * | > |*** ^ > / \ / \ > / \ / \ > / \ / \ > / \ / \ > ----------- ----------- > tree tree > > What does each entity need to know? > > * Seeker: It only needs to be configured with a resolver (=LoST > server). See DHCP and DNS-based mechanism (i.e., a dynamic > discovery mechanism). Agreed. > > * Resolver: It needs to be configured with the FG address, i.e., it > needs to know at least one FG. Ideally, it knows which FG is > responsible for which region. In this case it might just contact > the right FG without contacting FGs. Additionally, the resolver > might also know some other LoST servers within its tree to speed-up > search. > Agreed on the needs-to-know one part. Caching takes care of the latter issue, without any special mechanism. > I assume that the addresses of FGs and LoST servers a resolver > knows is largely based on manual configuration? I don't like manual configuration, but since this involves trust and policies/politics, I don't see much hope for something else. If the forest guide is run by the VSP, one can imagine that this is configured in the same way as for resolvers, using the VSP's domain name. > > The resolver will also cache service boundaries to speed up future > search attempts. Service boundaries and mappings, yes. > > * Forest Guide: The FGs need to be aware of each other. This is > most likely be based on manual configuration. For example, the FG > is manually configured with the address of the FG in Germany. The > FG also needs to know the service boundaries of each FG. This might > also be exchanged out of band. Yes. > > Are my observations largely correct? > > Ciao > Hannes > > PS: The term 'tree' is a bit misleading since it collectively > refers to the LoST server below a FG. The figure only shows > resolves that are part of this tree but does not depict > authoritative LoST servers. Resolvers aren't really part of the tree, since the tree is for authoritative servers only. Did I mess this up in the draft? > > _______________________________________________ > 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 Sep 26 00:36:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS4fh-0000cM-GD; Tue, 26 Sep 2006 00:35:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS4fg-0000cH-EJ for ecrit@ietf.org; Tue, 26 Sep 2006 00:35:52 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS4ff-0007i9-Kn for ecrit@ietf.org; Tue, 26 Sep 2006 00:35:52 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k8Q4ZoYM012714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 25 Sep 2006 21:35:50 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k8Q4ZmdD026501 for ; Mon, 25 Sep 2006 21:35:49 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Sep 2006 21:35:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Sep 2006 21:35:47 -0700 Message-ID: <21A52261514BE844AB662C1C21A29EA9289515@NAEX13.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Indication of PSAP Confidence Level in a LoST Query Response thread-index: AcbhJTymKi43IVD/SMyhza545FbczQ== From: "Edge, Stephen" To: X-OriginalArrivalTime: 26 Sep 2006 04:35:48.0686 (UTC) FILETIME=[3D6756E0:01C6E125] X-Spam-Score: 1.1 (+) X-Scan-Signature: 8a961490db2a74c7613bf0201229f176 Subject: [Ecrit] Indication of PSAP Confidence Level in a LoST Query Response 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="===============0402243125==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0402243125== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E125.3D477DF7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E125.3D477DF7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All Here is a topic that may or may not be new but maybe not yet presented in this light. In the not so distant future and certainly within the possible lifetime of the LoST capability, it may be possible using new algorithms and additional processing and storage availability to determine the probability that a particular PSAP URI is the correct one for a provided geographic or civil location (taking account of the fact that any provided location will often include, implicitly or explicitly, some area of uncertainty). This capability is possible in principle even today; it is just that the required amount of processing and storage may be too high (or the ability of currently known algorithms too low) to allow realistic and cost effective implementation. Assuming that a probability value, AKA confidence level, was provided in a LoST response, it would be possible with some solutions being developed (e.g. 3GPP and maybe 3GPP2) to obtain a more exact location for a wireless (or maybe wireline) user if the confidence value was not high and no significant delay had yet been expended to obtain the initial location. That would then allow a second LoST query with a higher probability of success. It would also permit a network to instigate the initial LoST query using simple location information such as cell ID requiring no time to obtain. The overall result could be significantly lower call delay wherever an initial location mapped unambiguously to a single PSAP URI and more reliable routing for callers in PSAP border areas. This capability may seem strange in a wireline environment where a terminal would typically stay put for extended periods of time allowing plenty of opportunity to obtain a location before an emergency call was originated. But in a wireless environment, it can be practically impossible to know location with anything but very coarse accuracy at any arbitrary point in time and the time needed to obtain a location more accurately can be significant. It should also be noted that such an enhancement to LoST could be mostly independent of the means used to obtain location (whether for the first or second query). In other words, such a capability need not (greatly) prejudice issues relating to the architecture, procedures and methods used to obtain location. Of course, such an enhancement to LoST might be added later after it was well established that algorithms and computational capability would be up to the task. But the addition of an extra optional parameter to a LoST response need not impact implementations that choose not to use it (either as a client or server). And later implementation support would be easier because it would not require any new standards change. (Of course, proprietary support would always be possible, but potentially dangerous because of the risk of LoST evolution in some other direction, such as provision of more than one PSAP URI.) One possible consequence of this proposal might be to encourage non-uniformity in the algorithms used to convert location to PSAP URI - meaning different implementations could occasionally deliver different URIs (and different confidence levels) for the same location input and same PSAP database map. But I wonder if this should really be an issue - e.g. it may well turn out that some algorithms are better (more reliable, faster etc.) than others and that a demonstration of this in a live environment would be a good way to ensure that the better ones eventually become the ones most widely adopted. Anyhow, please comment on this. Kind Regards Stephen ------_=_NextPart_001_01C6E125.3D477DF7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Indication of PSAP Confidence Level in a LoST Query = Response

Hi All

Here is a topic that may or may not be new but maybe not yet presented in this light. In the not = so distant future and certainly within the possible lifetime of the LoST capability, it may be possible using new = algorithms and additional processing and storage availability to = determine the probability that a particular PSAP URI is the correct one = for a provided = geographic or civil location (taking account of the fact that any provided location will often include, = implicitly or = explicitly, some = area of uncertainty). This = capability is possible in = principle = even today; it is just = that the required amount of processing and storage may be too = high = (or the ability of = currently = known algorithms too = low) to = allow realistic = and cost effective implementation.

Assuming that a probability value, AKA confidence level, = was provided in a = LoST response, it = would be possible with some solutions being developed (e.g. 3GPP and = maybe 3GPP2) to obtain a more exact location for a wireless (or maybe wireline) user if = the confidence value was not high and no significant delay had yet been expended to obtain the initial location. That would then = allow a second LoST query with a higher probability of success. It would also permit a = network to instigate the initial LoST query using simple location = information such as cell ID requiring no time = to obtain. The overall result could be significantly lower call delay = wherever an initial location mapped unambiguously to a single PSAP URI and more reliable = routing for callers in PSAP border areas.

This capability may seem strange in a wireline environment where a terminal would typically stay put for extended periods of time allowing plenty of opportunity to obtain a location before an emergency call was originated. But in a wireless environment, it can be practically impossible to know location with anything but very coarse accuracy at any arbitrary point in time and the time needed to obtain a location more accurately can be significant. = It should also be noted that such an enhancement to LoST could = be mostly independent of the means = used to obtain = location (whether = for the first or second query). = In = other = words, such = a capability need not (greatly) prejudice = issues relating = to the architecture, procedures = and methods used to obtain location.

Of course, such an enhancement to LoST might be added = later after it was well established that algorithms and computational = capability would be up to the task. But the addition of an extra optional parameter to = a LoST response need not impact implementations that choose not to use it (either = as a client or server). And later implementation support would be easier = because it would not require any new standards change. (Of course, = proprietary support would always be possible, but potentially dangerous = because of the = risk of LoST evolution in some other direction, such as provision of = more than one PSAP URI.)

One possible consequence of this proposal might = be to encourage non-uniformity in the algorithms used to convert = location to PSAP URI – meaning different implementations could occasionally deliver = different URIs (and different confidence levels) for the same location = input and same PSAP database map. But I wonder if this should really be an = issue – e.g. it may well turn out that some algorithms are = better (more reliable, faster etc.) than others and that a demonstration of this in a = live environment would be a good way to ensure that the better ones = eventually become the = ones most = widely = adopted.

Anyhow, please comment on this.

Kind Regards

Stephen

------_=_NextPart_001_01C6E125.3D477DF7-- --===============0402243125== 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 --===============0402243125==-- From ecrit-bounces@ietf.org Tue Sep 26 02:58:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS6tp-0005LF-Ls; Tue, 26 Sep 2006 02:58:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS6tn-0005GI-T2 for ecrit@ietf.org; Tue, 26 Sep 2006 02:58:35 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS6td-0000RI-3U for ecrit@ietf.org; Tue, 26 Sep 2006 02:58:35 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Sep 2006 01:58:20 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Tue, 26 Sep 2006 01:58:20 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Sep 2006 01:58:19 -0500 Message-ID: From: "Thomson, Martin" To: "Edge, Stephen" , Date: Tue, 26 Sep 2006 01:58:15 -0500 Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a LoST Query Response MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 26 Sep 2006 06:58:19.0322 (UTC) FILETIME=[25FAD9A0:01C6E139] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <21A52261514BE844AB662C1C21A29EA9289515@NAEX13.na.qualcomm.com> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Indication of PSAP Confidence Level in a LoST Query Response Thread-Index: AcbhJTymKi43IVD/SMyhza545FbczQADatyg X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede 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="===============1259633460==" Errors-To: ecrit-bounces@ietf.org --===============1259633460== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message SGkgU3RlcGhlbiwNCg0KSSBtdXN0IGFkbWl0LCB0aGF0IEkgY2Fu4oCZdCBzZWUgYW55IHRhbmdp YmxlIGJlbmVmaXRzIGZvciB0aGlzIHJpZ2h0IG5vdyDigJMgdGhhdCBpcyBwcm9iYWJseSBnb2lu ZyB0byBiZSB0aGUgYmlnZ2VzdCBwb2ludCBsZXZlbGVkIGFnYWluc3QgdGhpcyBwcm9wb3NhbC4N Cg0KVGhlc2Ugc29ydHMgb2YgZGlzY3Vzc2lvbiBoYXZlIGJlZW4gcnVuIGluIHRoZSBwYXN0LiAg Q29uc2lkZXIgdGhlIGRpc2N1c3Npb25zIG9uIHdoZXRoZXIgb3Igbm90IHVuY2VydGFpbnR5IHNo b3VsZCBiZSBpbmNsdWRlZCBpbiBMb1NUIChjaGVjayB0aGUgYXJjaGl2ZXM7IGl0IHdhcyBpbiB0 aGUgbGFzdCBmZXcgd2Vla3MpLiAgQW5kIEdFT1BSSVYgaGF2ZSBkaXNjdXNzZWQgY29uZmlkZW5j ZSBvbiB0aGUgcGFzdCwgYW5kIGFzaWRlIGZyb20gcHJvYmxlbXMgd2l0aCBwZW9wbGUgdW5kZXJz dGFuZGluZyB0aGUgY29uY2VwdHMsIHRoZSBtYWluIHBvaW50IGFnYWluc3QgaXRzIGluY2x1c2lv biB3YXMgdGhlIGxhY2sgb2YgcGVyY2VpdmVkIGJlbmVmaXQuDQoNCllvdSBhcmUgcHJvYmFibHkg Y29ycmVjdCwgaW4gdGhhdCB3ZSBkb27igJl0IGtub3cgdG9kYXkgaG93IHdlIGNvdWxkIGJlbmVm aXQgZnJvbSB0aGluZ3MgbGlrZSB1bmNlcnRhaW50eSBhbmQgY29uZmlkZW5jZSBpbiB0aGUgZnV0 dXJlLiAgQ2VydGFpbmx5LCB0aGVyZSBpcyB3aXNkb20gaW4gZHJhd2luZyBhIGxpbmUgYW5kIHNh eWluZyAiV2FyZSBZZSwgSGVyZSBCZSBEcmFnb25zIi4gIEV2ZW4gaWYgeW91IGtub3cgdGhhdCB0 aGVyZSBhcmUgcGVvcGxlIGxpdmluZyBvbiB0aGUgb3RoZXIgc2lkZSBvZiB0aGF0IGxpbmUgaGFw cGlseSwgeW91IGNhbiBnZXQgb24gd2l0aCB5b3VyIGJ1c2luZXNzLCB3aGljaCBpcyBlbmdpbmVl cmluZyB3b3JrYWJsZSBzb2x1dGlvbnMuDQoNCkkgc3VzcGVjdCB0aGF0IHRoaXMgaXMgcHJpbWFy aWx5IGJlY2F1c2UgcGVvcGxlIGhhdmUgdHJvdWJsZSB3aXRoIHRoZSB2YWdhcmllcyBpbmhlcmVu dCBpbiBtb2JpbGUgYW5kIHdpcmVsZXNzIHN5c3RlbXMuICBGb3IgTG9TVCwgaW4gdGhlIGhlcmUg YW5kIG5vdywgd2hhdCB5b3UgYXJlIGFza2luZyBmb3IgaXMgYSBzbWFsbCBjaGFuZ2UgaW4gdGhl IHVuZGVybHlpbmcgcGhpbG9zb3BoeS4gIFRoaXMgcGhpbG9zb3BoeSBpc24ndCBuZWNlc3Nhcmls eSB3cml0dGVuIGRvd24sIGJ1dCB5b3Ugd2lsbCBmaW5kIHRoYXQgdGhpcyBXRyBpcyBjdXJyZW50 bHkgb3BlcmF0aW5nIHVuZGVyIHRoZSBhc3N1bXB0aW9uIHRoYXQgaXRzIGlucHV0cyB3aWxsIGJl IHNpbXBsZS4gIFRoaXMgZ2l2ZXMgc29saWQsIHJlcGVhdGFibGUgcmVzdWx0czsgeW91IGNhbiB3 cml0ZSBhbGdvcml0aG1zIHRvIHRoYXQ7IGFuZCBhbG1vc3QgYW55b25lIGNhbiBnZXQgaXQgcmln aHQuICBIYXZpbmcgb25lIHJlc3VsdCBpcyBuaWNlIC0gd2UgZG9uJ3Qgd2FudCByZXF1ZXN0IGZv cmtpbmcsIHdoaWNoIGlzIGEgcG9zc2liaWxpdHkgdW5sZXNzIHlvdSBoYXZlIGEgY2xlYXIgb25l LXRvLW9uZSBtYXBwaW5nIGZyb20gbG9jYXRpb24gdG8gVVJJLi4uDQoNCglsb2NhdGlvbiAtPiBG RyAtPiBGRyAoLT4gRkcgLi4uKSAtPiBUcmVlIC0+IFVSSQ0KDQpZb3UgdW5kZXJzdGFuZCB0aGUg dmFnYXJpZXMsIGFuZCBhcmUgY29tZm9ydGFibGUgd2l0aCB0aGVtLCBidXQgdGhlc2Ugc2NhcmUg dGhlIHdpbGxpZXMgb3V0IG9mIG1vc3QgcGVvcGxlIC0gYmVjYXVzZSB5b3UgZG9uJ3QgZ2V0IHJl c3VsdHMgaW4gbmljZSB0aWR5IGJveGVzLiAgSXQncyBhbHNvIGhhcmRlciB0byBkZXNpZ24gYSBz eXN0ZW0gdGhhdCBkZWFscyB3aXRoIGZ1enp5IGlucHV0cy4gIFRvIHN0YXJ0IHdpdGgsIHlvdSBu ZWVkIGEgcmVhbGx5IGNvbXBlbGxpbmcgcmVhc29uIHRvIGRvIGl0LiAgVGhlbiwgeW91IG5lZWQg dG8gbWFrZSBpdCBzbyBlYXN5IHRvIGRvIHRoYXQgbm90IGRvaW5nIGl0IHdvdWxkIHNlZW0gcmVj YWxjaXRyYW50Lg0KDQpJIHBlcnNvbmFsbHkgbGlrZSB0aGUgaWRlYSBvZiBidWlsZGluZyBpbiBh IGxpdHRsZSB0b2xlcmFuY2UgaW50byB0aGUgd2hvbGUgc3lzdGVtLiAgQW5kIGJlaW5nIGFibGUg dG8gY29udmV5IHRoaXMgc29ydCBvZiBpbmZvcm1hdGlvbiBjb3VsZCBiZSB1c2VmdWwgb3V0c2lk ZSBvZiBhbiBlbWVyZ2VuY3kgc2l0dWF0aW9uIGFzIGEgc29ydCBvZiB0dW5pbmcgbWVjaGFuaXNt LiAgQ2VydGFpbmx5LCBpdCB3b3VsZCBiZSB1c2VmdWwgaW4gY29tYmluYXRpb24gd2l0aCBsb2Nh dGlvbiB1bmNlcnRhaW50eSBhbmQgY29uZmlkZW5jZSB0byBrbm93IHdoZXRoZXIgb3Igbm90IGN1 cnJlbnQgbG9jYXRpb24gaW5mb3JtYXRpb24gaXMgYWRlcXVhdGUuDQoNCkJ1dCB0aGlzIGlzIGZy b20gdGhlIHBlcnNvbiB0aGF0IHJlbWluZGVkIEdFT1BSSVYgdGhhdCBsb2NhdGlvbiBpc24ndCBh bHdheXMgYSBzaW1wbGUgcG9pbnQgaW4gc3BhY2UuDQogDQpDaGVlcnMsDQpNYXJ0aW4NCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogRWRnZSwgU3RlcGhl biBbbWFpbHRvOnNlZGdlQHF1YWxjb21tLmNvbV0gDQpTZW50OiBUdWVzZGF5LCAyNiBTZXB0ZW1i ZXIgMjAwNiAyOjM2IFBNDQpUbzogZWNyaXRAaWV0Zi5vcmcNClN1YmplY3Q6IFtFY3JpdF0gSW5k aWNhdGlvbiBvZiBQU0FQIENvbmZpZGVuY2UgTGV2ZWwgaW4gYSBMb1NUIFF1ZXJ5IFJlc3BvbnNl DQoNCkhpIEFsbA0KSGVyZSBpcyBhIHRvcGljIHRoYXQgbWF5IG9yIG1heSBub3QgYmUgbmV3IGJ1 dCBtYXliZSBub3QgeWV0IHByZXNlbnRlZCBpbiB0aGlzIGxpZ2h0LiBJbiB0aGUgbm90IHNvIGRp c3RhbnQgZnV0dXJlIGFuZCBjZXJ0YWlubHkgd2l0aGluIHRoZSBwb3NzaWJsZSBsaWZldGltZSBv ZiB0aGUgTG9TVCBjYXBhYmlsaXR5LCBpdCBtYXkgYmUgcG9zc2libGUgdXNpbmcgbmV3IGFsZ29y aXRobXMgYW5kIGFkZGl0aW9uYWwgcHJvY2Vzc2luZyBhbmQgc3RvcmFnZSBhdmFpbGFiaWxpdHkg dG8gZGV0ZXJtaW5lIHRoZSBwcm9iYWJpbGl0eSB0aGF0IGEgcGFydGljdWxhciBQU0FQIFVSSSBp cyB0aGUgY29ycmVjdCBvbmUgZm9yIGEgcHJvdmlkZWQgZ2VvZ3JhcGhpYyBvciBjaXZpbCBsb2Nh dGlvbiAodGFraW5nIGFjY291bnQgb2YgdGhlIGZhY3QgdGhhdCBhbnkgcHJvdmlkZWQgbG9jYXRp b24gd2lsbCBvZnRlbiBpbmNsdWRlLCBpbXBsaWNpdGx5IG9yIGV4cGxpY2l0bHksIHNvbWUgYXJl YSBvZiB1bmNlcnRhaW50eSkuIFRoaXMgY2FwYWJpbGl0eSBpcyBwb3NzaWJsZSBpbiBwcmluY2lw bGUgZXZlbiB0b2RheTsgaXQgaXMganVzdCB0aGF0IHRoZSByZXF1aXJlZCBhbW91bnQgb2YgcHJv Y2Vzc2luZyBhbmQgc3RvcmFnZSBtYXkgYmUgdG9vIGhpZ2ggKG9yIHRoZSBhYmlsaXR5IG9mIGN1 cnJlbnRseSBrbm93biBhbGdvcml0aG1zIHRvbyBsb3cpIHRvIGFsbG93IHJlYWxpc3RpYyBhbmQg Y29zdCBlZmZlY3RpdmUgaW1wbGVtZW50YXRpb24uDQoNCkFzc3VtaW5nIHRoYXQgYSBwcm9iYWJp bGl0eSB2YWx1ZSwgQUtBIGNvbmZpZGVuY2UgbGV2ZWwsIHdhcyBwcm92aWRlZCBpbiBhIExvU1Qg cmVzcG9uc2UsIGl0IHdvdWxkIGJlIHBvc3NpYmxlIHdpdGggc29tZSBzb2x1dGlvbnMgYmVpbmcg ZGV2ZWxvcGVkIChlLmcuIDNHUFAgYW5kIG1heWJlIDNHUFAyKSB0byBvYnRhaW4gYSBtb3JlIGV4 YWN0IGxvY2F0aW9uIGZvciBhIHdpcmVsZXNzIChvciBtYXliZSB3aXJlbGluZSkgdXNlciBpZiB0 aGUgY29uZmlkZW5jZSB2YWx1ZSB3YXMgbm90IGhpZ2ggYW5kIG5vIHNpZ25pZmljYW50IGRlbGF5 IGhhZCB5ZXQgYmVlbiBleHBlbmRlZCB0byBvYnRhaW4gdGhlIGluaXRpYWwgbG9jYXRpb24uIFRo YXQgd291bGQgdGhlbiBhbGxvdyBhIHNlY29uZCBMb1NUIHF1ZXJ5IHdpdGggYSBoaWdoZXIgcHJv YmFiaWxpdHkgb2Ygc3VjY2Vzcy4gSXQgd291bGQgYWxzbyBwZXJtaXQgYSBuZXR3b3JrIHRvIGlu c3RpZ2F0ZSB0aGUgaW5pdGlhbCBMb1NUIHF1ZXJ5IHVzaW5nIHNpbXBsZSBsb2NhdGlvbiBpbmZv cm1hdGlvbiBzdWNoIGFzIGNlbGwgSUQgcmVxdWlyaW5nIG5vIHRpbWUgdG8gb2J0YWluLiBUaGUg b3ZlcmFsbCByZXN1bHQgY291bGQgYmUgc2lnbmlmaWNhbnRseSBsb3dlciBjYWxsIGRlbGF5IHdo ZXJldmVyIGFuIGluaXRpYWwgbG9jYXRpb24gbWFwcGVkIHVuYW1iaWd1b3VzbHkgdG8gYSBzaW5n bGUgUFNBUCBVUkkgYW5kIG1vcmUgcmVsaWFibGUgcm91dGluZyBmb3IgY2FsbGVycyBpbiBQU0FQ IGJvcmRlciBhcmVhcy4NCg0KVGhpcyBjYXBhYmlsaXR5IG1heSBzZWVtIHN0cmFuZ2UgaW4gYSB3 aXJlbGluZSBlbnZpcm9ubWVudCB3aGVyZSBhIHRlcm1pbmFsIHdvdWxkIHR5cGljYWxseSBzdGF5 IHB1dCBmb3IgZXh0ZW5kZWQgcGVyaW9kcyBvZiB0aW1lIGFsbG93aW5nIHBsZW50eSBvZiBvcHBv cnR1bml0eSB0byBvYnRhaW4gYSBsb2NhdGlvbiBiZWZvcmUgYW4gZW1lcmdlbmN5IGNhbGwgd2Fz IG9yaWdpbmF0ZWQuIEJ1dCBpbiBhIHdpcmVsZXNzIGVudmlyb25tZW50LCBpdCBjYW4gYmUgcHJh Y3RpY2FsbHkgaW1wb3NzaWJsZSB0byBrbm93IGxvY2F0aW9uIHdpdGggYW55dGhpbmcgYnV0IHZl cnkgY29hcnNlIGFjY3VyYWN5IGF0IGFueSBhcmJpdHJhcnkgcG9pbnQgaW4gdGltZSBhbmQgdGhl IHRpbWUgbmVlZGVkIHRvIG9idGFpbiBhIGxvY2F0aW9uIG1vcmUgYWNjdXJhdGVseSBjYW4gYmUg c2lnbmlmaWNhbnQuIEl0IHNob3VsZCBhbHNvIGJlIG5vdGVkIHRoYXQgc3VjaCBhbiBlbmhhbmNl bWVudCB0byBMb1NUIGNvdWxkIGJlIG1vc3RseSBpbmRlcGVuZGVudCBvZiB0aGUgbWVhbnMgdXNl ZCB0byBvYnRhaW4gbG9jYXRpb24gKHdoZXRoZXIgZm9yIHRoZSBmaXJzdCBvciBzZWNvbmQgcXVl cnkpLiBJbiBvdGhlciB3b3Jkcywgc3VjaCBhIGNhcGFiaWxpdHkgbmVlZCBub3QgKGdyZWF0bHkp IHByZWp1ZGljZSBpc3N1ZXMgcmVsYXRpbmcgdG8gdGhlIGFyY2hpdGVjdHVyZSwgcHJvY2VkdXJl cyBhbmQgbWV0aG9kcyB1c2VkIHRvIG9idGFpbiBsb2NhdGlvbi4NCg0KT2YgY291cnNlLCBzdWNo IGFuIGVuaGFuY2VtZW50IHRvIExvU1QgbWlnaHQgYmUgYWRkZWQgbGF0ZXIgYWZ0ZXIgaXQgd2Fz IHdlbGwgZXN0YWJsaXNoZWQgdGhhdCBhbGdvcml0aG1zIGFuZCBjb21wdXRhdGlvbmFsIGNhcGFi aWxpdHkgd291bGQgYmUgdXAgdG8gdGhlIHRhc2suIEJ1dCB0aGUgYWRkaXRpb24gb2YgYW4gZXh0 cmEgb3B0aW9uYWwgcGFyYW1ldGVyIHRvIGEgTG9TVCByZXNwb25zZSBuZWVkIG5vdCBpbXBhY3Qg aW1wbGVtZW50YXRpb25zIHRoYXQgY2hvb3NlIG5vdCB0byB1c2UgaXQgKGVpdGhlciBhcyBhIGNs aWVudCBvciBzZXJ2ZXIpLiBBbmQgbGF0ZXIgaW1wbGVtZW50YXRpb24gc3VwcG9ydCB3b3VsZCBi ZSBlYXNpZXIgYmVjYXVzZSBpdCB3b3VsZCBub3QgcmVxdWlyZSBhbnkgbmV3IHN0YW5kYXJkcyBj aGFuZ2UuIChPZiBjb3Vyc2UsIHByb3ByaWV0YXJ5IHN1cHBvcnQgd291bGQgYWx3YXlzIGJlIHBv c3NpYmxlLCBidXQgcG90ZW50aWFsbHkgZGFuZ2Vyb3VzIGJlY2F1c2Ugb2YgdGhlIHJpc2sgb2Yg TG9TVCBldm9sdXRpb24gaW4gc29tZSBvdGhlciBkaXJlY3Rpb24sIHN1Y2ggYXMgcHJvdmlzaW9u IG9mIG1vcmUgdGhhbiBvbmUgUFNBUCBVUkkuKQ0KDQpPbmUgcG9zc2libGUgY29uc2VxdWVuY2Ug b2YgdGhpcyBwcm9wb3NhbCBtaWdodCBiZSB0byBlbmNvdXJhZ2Ugbm9uLXVuaWZvcm1pdHkgaW4g dGhlIGFsZ29yaXRobXMgdXNlZCB0byBjb252ZXJ0IGxvY2F0aW9uIHRvIFBTQVAgVVJJIOKAkyBt ZWFuaW5nIGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnMgY291bGQgb2NjYXNpb25hbGx5IGRlbGl2 ZXIgZGlmZmVyZW50IFVSSXMgKGFuZCBkaWZmZXJlbnQgY29uZmlkZW5jZSBsZXZlbHMpIGZvciB0 aGUgc2FtZSBsb2NhdGlvbiBpbnB1dCBhbmQgc2FtZSBQU0FQIGRhdGFiYXNlIG1hcC4gQnV0IEkg d29uZGVyIGlmIHRoaXMgc2hvdWxkIHJlYWxseSBiZSBhbiBpc3N1ZSDigJMgZS5nLiBpdCBtYXkg d2VsbCB0dXJuIG91dCB0aGF0IHNvbWUgYWxnb3JpdGhtcyBhcmUgYmV0dGVyIChtb3JlIHJlbGlh YmxlLCBmYXN0ZXIgZXRjLikgdGhhbiBvdGhlcnMgYW5kIHRoYXQgYSBkZW1vbnN0cmF0aW9uIG9m IHRoaXMgaW4gYSBsaXZlIGVudmlyb25tZW50IHdvdWxkIGJlIGEgZ29vZCB3YXkgdG8gZW5zdXJl IHRoYXQgdGhlIGJldHRlciBvbmVzIGV2ZW50dWFsbHkgYmVjb21lIHRoZSBvbmVzIG1vc3Qgd2lk ZWx5IGFkb3B0ZWQuDQoNCkFueWhvdywgcGxlYXNlIGNvbW1lbnQgb24gdGhpcy4NCktpbmQgUmVn YXJkcw0KU3RlcGhlbg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpU aGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkN CmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGlu Zm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFu eSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJd --===============1259633460== 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 --===============1259633460==-- From ecrit-bounces@ietf.org Tue Sep 26 07:29:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSB7Y-0000cF-2X; Tue, 26 Sep 2006 07:29:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSB7X-0000c9-77 for ecrit@ietf.org; Tue, 26 Sep 2006 07:29:03 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSB7W-0002Ud-OQ for ecrit@ietf.org; Tue, 26 Sep 2006 07:29:03 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GSB7L-0002R0-N4; Tue, 26 Sep 2006 06:28:53 -0500 From: "Brian Rosen" To: "'Thomson, Martin'" , "'Edge, Stephen'" , Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a LoST QueryResponse Date: Tue, 26 Sep 2006 07:28:49 -0400 Message-ID: <093501c6e15e$f302a4d0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbhJTymKi43IVD/SMyhza545FbczQADatygAArByEA= In-Reply-To: X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba 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: , Errors-To: ecrit-bounces@ietf.org I'm not sure I understand what you are proposing. The service boundaries are hard edged polygons. If you put a point in, you get an exact answer out. If you put a shape in, then we could have some kind of overlap of the boundary polygons with the shape, and get uncertainty from that. Is that what you were proposing? If so, I think I would support some kind of output that told you how close of a fit we got. If that's not it, perhaps you would explain in more detail what you propose. I do think we are pushing for the LoST resolver to be simple and deterministic. The reason is that it is not in a position to understand what the tradeoffs are. In general, the closer you get to the origin of the location information, the more you understand what is actually happening on the ground. We want earlier elements to make the decisions, and not later elements. Thus we insist that if you have more than one location, the client chooses, and not the server. If we force the client to interpret inexactness, then I think giving it as much information to make the choice as we can is a useful thing to do. Brian > -----Original Message----- > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > Sent: Tuesday, September 26, 2006 2:58 AM > To: Edge, Stephen; ecrit@ietf.org > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a LoST > QueryResponse > > Hi Stephen, > > I must admit, that I can't see any tangible benefits for this right now - > that is probably going to be the biggest point leveled against this > proposal. > > These sorts of discussion have been run in the past. Consider the > discussions on whether or not uncertainty should be included in LoST > (check the archives; it was in the last few weeks). And GEOPRIV have > discussed confidence on the past, and aside from problems with people > understanding the concepts, the main point against its inclusion was the > lack of perceived benefit. > > You are probably correct, in that we don't know today how we could benefit > from things like uncertainty and confidence in the future. Certainly, > there is wisdom in drawing a line and saying "Ware Ye, Here Be Dragons". > Even if you know that there are people living on the other side of that > line happily, you can get on with your business, which is engineering > workable solutions. > > I suspect that this is primarily because people have trouble with the > vagaries inherent in mobile and wireless systems. For LoST, in the here > and now, what you are asking for is a small change in the underlying > philosophy. This philosophy isn't necessarily written down, but you will > find that this WG is currently operating under the assumption that its > inputs will be simple. This gives solid, repeatable results; you can > write algorithms to that; and almost anyone can get it right. Having one > result is nice - we don't want request forking, which is a possibility > unless you have a clear one-to-one mapping from location to URI... > > location -> FG -> FG (-> FG ...) -> Tree -> URI > > You understand the vagaries, and are comfortable with them, but these > scare the willies out of most people - because you don't get results in > nice tidy boxes. It's also harder to design a system that deals with > fuzzy inputs. To start with, you need a really compelling reason to do > it. Then, you need to make it so easy to do that not doing it would seem > recalcitrant. > > I personally like the idea of building in a little tolerance into the > whole system. And being able to convey this sort of information could be > useful outside of an emergency situation as a sort of tuning mechanism. > Certainly, it would be useful in combination with location uncertainty and > confidence to know whether or not current location information is > adequate. > > But this is from the person that reminded GEOPRIV that location isn't > always a simple point in space. > > Cheers, > Martin > > ________________________________________ > From: Edge, Stephen [mailto:sedge@qualcomm.com] > Sent: Tuesday, 26 September 2006 2:36 PM > To: ecrit@ietf.org > Subject: [Ecrit] Indication of PSAP Confidence Level in a LoST Query > Response > > Hi All > Here is a topic that may or may not be new but maybe not yet presented in > this light. In the not so distant future and certainly within the possible > lifetime of the LoST capability, it may be possible using new algorithms > and additional processing and storage availability to determine the > probability that a particular PSAP URI is the correct one for a provided > geographic or civil location (taking account of the fact that any provided > location will often include, implicitly or explicitly, some area of > uncertainty). This capability is possible in principle even today; it is > just that the required amount of processing and storage may be too high > (or the ability of currently known algorithms too low) to allow realistic > and cost effective implementation. > > Assuming that a probability value, AKA confidence level, was provided in a > LoST response, it would be possible with some solutions being developed > (e.g. 3GPP and maybe 3GPP2) to obtain a more exact location for a wireless > (or maybe wireline) user if the confidence value was not high and no > significant delay had yet been expended to obtain the initial location. > That would then allow a second LoST query with a higher probability of > success. It would also permit a network to instigate the initial LoST > query using simple location information such as cell ID requiring no time > to obtain. The overall result could be significantly lower call delay > wherever an initial location mapped unambiguously to a single PSAP URI and > more reliable routing for callers in PSAP border areas. > > This capability may seem strange in a wireline environment where a > terminal would typically stay put for extended periods of time allowing > plenty of opportunity to obtain a location before an emergency call was > originated. But in a wireless environment, it can be practically > impossible to know location with anything but very coarse accuracy at any > arbitrary point in time and the time needed to obtain a location more > accurately can be significant. It should also be noted that such an > enhancement to LoST could be mostly independent of the means used to > obtain location (whether for the first or second query). In other words, > such a capability need not (greatly) prejudice issues relating to the > architecture, procedures and methods used to obtain location. > > Of course, such an enhancement to LoST might be added later after it was > well established that algorithms and computational capability would be up > to the task. But the addition of an extra optional parameter to a LoST > response need not impact implementations that choose not to use it (either > as a client or server). And later implementation support would be easier > because it would not require any new standards change. (Of course, > proprietary support would always be possible, but potentially dangerous > because of the risk of LoST evolution in some other direction, such as > provision of more than one PSAP URI.) > > One possible consequence of this proposal might be to encourage non- > uniformity in the algorithms used to convert location to PSAP URI - > meaning different implementations could occasionally deliver different > URIs (and different confidence levels) for the same location input and > same PSAP database map. But I wonder if this should really be an issue - > e.g. it may well turn out that some algorithms are better (more reliable, > faster etc.) than others and that a demonstration of this in a live > environment would be a good way to ensure that the better ones eventually > become the ones most widely adopted. > > Anyhow, please comment on this. > Kind Regards > Stephen > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 26 08:26:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSC1I-0006YG-8j; Tue, 26 Sep 2006 08:26:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSC1H-0006XX-GU for ecrit@ietf.org; Tue, 26 Sep 2006 08:26:39 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSC1G-00083d-1x for ecrit@ietf.org; Tue, 26 Sep 2006 08:26:39 -0400 Received: from [192.168.0.41] (pool-141-153-175-20.mad.east.verizon.net [141.153.175.20]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k8QCQRu9027453 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Tue, 26 Sep 2006 08:26:28 -0400 (EDT) In-Reply-To: <093501c6e15e$f302a4d0$640fa8c0@cis.neustar.com> References: <093501c6e15e$f302a4d0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <08D4AFB5-4443-402D-844F-E42F5186EBD5@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Indication of PSAP Confidence Level in a LoST QueryResponse Date: Tue, 26 Sep 2006 08:26:20 -0400 To: Brian Rosen X-Mailer: Apple Mail (2.752.2) X-PerlMx-Spam: Gauge=XXII, Probability=22%, X-Seen-By filter1.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'll also add that earlier discussion has yielded the insight that sector-size areas are pretty useless for call routing, as there is a significant probability of mis-routes. This probability won't be reduced all that much by fancy area maximization techniques or anything else since you simply can't tell which of the PSAP serving areas you're in. With area maximization, for example, users in a cell sector will simply be assigned to whatever PSAP service area dominates the cell sector. On average, across cell towers, that will still make it a 50/50 toss-up. For dispatch, mid-sized areas of uncertainty are useful, corresponding to the typical FCC-compliant uncertainty regions of a few hundred feet. However, worrying that such areas span multiple PSAPs and then trying to pick the right one seems rather pointless (sorry...), given the complexity. (If clients really care, they can randomly sample the area, essentially doing a Monte-Carlo simulation, which will yield an area maximization by design.) Thus, I just don't see the benefit. Either the area of uncertainty is too large for routing, as it is for tower/face information, or it is too small to worry about the right PSAP, and can be treated as a point for PSAP selection purposes. Henning On Sep 26, 2006, at 7:28 AM, Brian Rosen wrote: > I'm not sure I understand what you are proposing. The service > boundaries > are hard edged polygons. If you put a point in, you get an exact > answer > out. If you put a shape in, then we could have some kind of > overlap of the > boundary polygons with the shape, and get uncertainty from that. > Is that > what you were proposing? > > If so, I think I would support some kind of output that told you > how close > of a fit we got. If that's not it, perhaps you would explain in > more detail > what you propose. > > I do think we are pushing for the LoST resolver to be simple and > deterministic. The reason is that it is not in a position to > understand > what the tradeoffs are. In general, the closer you get to the > origin of the > location information, the more you understand what is actually > happening on > the ground. We want earlier elements to make the decisions, and > not later > elements. Thus we insist that if you have more than one location, the > client chooses, and not the server. If we force the client to > interpret > inexactness, then I think giving it as much information to make the > choice > as we can is a useful thing to do. > > Brian > >> -----Original Message----- >> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] >> Sent: Tuesday, September 26, 2006 2:58 AM >> To: Edge, Stephen; ecrit@ietf.org >> Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a LoST >> QueryResponse >> >> Hi Stephen, >> >> I must admit, that I can't see any tangible benefits for this >> right now - >> that is probably going to be the biggest point leveled against this >> proposal. >> >> These sorts of discussion have been run in the past. Consider the >> discussions on whether or not uncertainty should be included in LoST >> (check the archives; it was in the last few weeks). And GEOPRIV have >> discussed confidence on the past, and aside from problems with people >> understanding the concepts, the main point against its inclusion >> was the >> lack of perceived benefit. >> >> You are probably correct, in that we don't know today how we could >> benefit >> from things like uncertainty and confidence in the future. >> Certainly, >> there is wisdom in drawing a line and saying "Ware Ye, Here Be >> Dragons". >> Even if you know that there are people living on the other side of >> that >> line happily, you can get on with your business, which is engineering >> workable solutions. >> >> I suspect that this is primarily because people have trouble with the >> vagaries inherent in mobile and wireless systems. For LoST, in >> the here >> and now, what you are asking for is a small change in the underlying >> philosophy. This philosophy isn't necessarily written down, but >> you will >> find that this WG is currently operating under the assumption that >> its >> inputs will be simple. This gives solid, repeatable results; you can >> write algorithms to that; and almost anyone can get it right. >> Having one >> result is nice - we don't want request forking, which is a >> possibility >> unless you have a clear one-to-one mapping from location to URI... >> >> location -> FG -> FG (-> FG ...) -> Tree -> URI >> >> You understand the vagaries, and are comfortable with them, but these >> scare the willies out of most people - because you don't get >> results in >> nice tidy boxes. It's also harder to design a system that deals with >> fuzzy inputs. To start with, you need a really compelling reason >> to do >> it. Then, you need to make it so easy to do that not doing it >> would seem >> recalcitrant. >> >> I personally like the idea of building in a little tolerance into the >> whole system. And being able to convey this sort of information >> could be >> useful outside of an emergency situation as a sort of tuning >> mechanism. >> Certainly, it would be useful in combination with location >> uncertainty and >> confidence to know whether or not current location information is >> adequate. >> >> But this is from the person that reminded GEOPRIV that location isn't >> always a simple point in space. >> >> Cheers, >> Martin >> >> ________________________________________ >> From: Edge, Stephen [mailto:sedge@qualcomm.com] >> Sent: Tuesday, 26 September 2006 2:36 PM >> To: ecrit@ietf.org >> Subject: [Ecrit] Indication of PSAP Confidence Level in a LoST Query >> Response >> >> Hi All >> Here is a topic that may or may not be new but maybe not yet >> presented in >> this light. In the not so distant future and certainly within the >> possible >> lifetime of the LoST capability, it may be possible using new >> algorithms >> and additional processing and storage availability to determine the >> probability that a particular PSAP URI is the correct one for a >> provided >> geographic or civil location (taking account of the fact that any >> provided >> location will often include, implicitly or explicitly, some area of >> uncertainty). This capability is possible in principle even today; >> it is >> just that the required amount of processing and storage may be too >> high >> (or the ability of currently known algorithms too low) to allow >> realistic >> and cost effective implementation. >> >> Assuming that a probability value, AKA confidence level, was >> provided in a >> LoST response, it would be possible with some solutions being >> developed >> (e.g. 3GPP and maybe 3GPP2) to obtain a more exact location for a >> wireless >> (or maybe wireline) user if the confidence value was not high and no >> significant delay had yet been expended to obtain the initial >> location. >> That would then allow a second LoST query with a higher >> probability of >> success. It would also permit a network to instigate the initial LoST >> query using simple location information such as cell ID requiring >> no time >> to obtain. The overall result could be significantly lower call delay >> wherever an initial location mapped unambiguously to a single PSAP >> URI and >> more reliable routing for callers in PSAP border areas. >> >> This capability may seem strange in a wireline environment where a >> terminal would typically stay put for extended periods of time >> allowing >> plenty of opportunity to obtain a location before an emergency >> call was >> originated. But in a wireless environment, it can be practically >> impossible to know location with anything but very coarse accuracy >> at any >> arbitrary point in time and the time needed to obtain a location more >> accurately can be significant. It should also be noted that such an >> enhancement to LoST could be mostly independent of the means used to >> obtain location (whether for the first or second query). In other >> words, >> such a capability need not (greatly) prejudice issues relating to the >> architecture, procedures and methods used to obtain location. >> >> Of course, such an enhancement to LoST might be added later after >> it was >> well established that algorithms and computational capability >> would be up >> to the task. But the addition of an extra optional parameter to a >> LoST >> response need not impact implementations that choose not to use it >> (either >> as a client or server). And later implementation support would be >> easier >> because it would not require any new standards change. (Of course, >> proprietary support would always be possible, but potentially >> dangerous >> because of the risk of LoST evolution in some other direction, >> such as >> provision of more than one PSAP URI.) >> >> One possible consequence of this proposal might be to encourage non- >> uniformity in the algorithms used to convert location to PSAP URI - >> meaning different implementations could occasionally deliver >> different >> URIs (and different confidence levels) for the same location input >> and >> same PSAP database map. But I wonder if this should really be an >> issue - >> e.g. it may well turn out that some algorithms are better (more >> reliable, >> faster etc.) than others and that a demonstration of this in a live >> environment would be a good way to ensure that the better ones >> eventually >> become the ones most widely adopted. >> >> Anyhow, please comment on this. >> Kind Regards >> Stephen >> --------------------------------------------------------------------- >> ----- >> ---------------------- >> This message is for the designated recipient only and may >> contain privileged, proprietary, or otherwise private information. >> If you have received it in error, please notify the sender >> immediately and delete the original. Any unauthorized use of >> this email is prohibited. >> --------------------------------------------------------------------- >> ----- >> ---------------------- >> [mf2] > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 26 18:41:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSLbM-0008I4-Ff; Tue, 26 Sep 2006 18:40:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSLYp-0006Zb-Aw for ecrit@ietf.org; Tue, 26 Sep 2006 18:37:55 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSLSR-0002HH-Ob for ecrit@ietf.org; Tue, 26 Sep 2006 18:31:22 -0400 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k8QMUvS09728; Tue, 26 Sep 2006 18:30:57 -0400 (EDT) Received: from [127.0.0.1] ([47.9.16.239] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Sep 2006 18:30:56 -0400 Message-ID: <4519AA1D.60803@nortel.com> Date: Tue, 26 Sep 2006 18:30:53 -0400 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Edge, Stephen" Subject: Re: [Ecrit] Indication of PSAP Confidence Level in a LoST Query Response References: <21A52261514BE844AB662C1C21A29EA9289515@NAEX13.na.qualcomm.com> In-Reply-To: <21A52261514BE844AB662C1C21A29EA9289515@NAEX13.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Sep 2006 22:30:56.0774 (UTC) FILETIME=[6F386A60:01C6E1BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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: , Errors-To: ecrit-bounces@ietf.org Your proposal assumes knowledge of a probability distribution of the target's location over the surface of the earth (or perhaps within a volume over the surface of the earth. Is this reasonable, or capable of approximation? I suspect it is possible only for certain access methods. Edge, Stephen wrote: > Hi All > > Here is a topic that may or may not be new but maybe not yet > presented in this light. In the not so distant future and certainly > within the possible lifetime of the LoST capability, it may be > possible using new algorithms and additional processing and storage > availability to determine the probability that a particular PSAP URI > is the correct one for a provided geographic or civil location > (taking account of the fact that any provided location will often > include, implicitly or explicitly, some area of uncertainty). This > capability is possible in principle even today; it is just that the > required amount of processing and storage may be too high (or the > ability of currently known algorithms too low) to allow realistic and > cost effective implementation. > ... _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 26 19:13:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSM7N-0004eT-0C; Tue, 26 Sep 2006 19:13:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSM7L-0004eO-Pr for ecrit@ietf.org; Tue, 26 Sep 2006 19:13:35 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSM7K-0007oc-F5 for ecrit@ietf.org; Tue, 26 Sep 2006 19:13:35 -0400 Received: from [192.168.0.109] ([::ffff:64.102.254.33]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Tue, 26 Sep 2006 19:13:14 -0400 id 015880D8.4519B40A.00004339 Message-ID: <4519B40F.8030103@thinkingcat.com> Date: Tue, 26 Sep 2006 19:13:19 -0400 From: Leslie Daigle User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] Hum for draft-polk-ecrit-dhc-lost-discovery-00.txt References: <000001c6db7c$03db01f0$1152150a@amer.cisco.com> <45102B8C.5080803@gmx.net> <45102D53.5020205@gmx.net> <45114C31.1060901@hxr.us> <4511C03D.9040100@thinkingcat.com> <4513974A.1000504@gmx.net> In-Reply-To: <4513974A.1000504@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 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: , Errors-To: ecrit-bounces@ietf.org Hi Hannes, Hannes Tschofenig wrote: > > I am just curious why the mechanisms used for SIP are not good enough > for our purpose. If you're referring to RFC3263 -- observe that 3263<3401 (the final publication number of the DDDS spec) :-) I.e., the SIP location service was defined when NAPTR-based application specification was caught in IESG-limbo-hell (yes, I remember when "final" documents disappeared into the IESG for 6 months at a stretch, and your AD didn't reply to your e-mail, EVER, and there WAS NO I-D TRACKER! *ahem* sorry... just had to get that twitch over with ;-) ). So -- if the SIP location service was defined today, it would have different text. > I just to make sure that I understand you right. With the third option > you would use the DHCP option to return an FQDN (instead of a domain > name) and use it as input to the U-NAPTR-based discovery found in the > LoST specification. Yes -- with the adjustment to the above that you & Andy later agreed on ("instead of an IP address"). That would align with the material in draft-ietf-ecrit-lost-01.txt -- i.e., that domain names are used in a U-NAPTR application to produce the actual URI(s) of the LoST server(s). I'd suggest this text: The option MAY contain multiple domain names, but these SHOULD refer to different NAPTR records, rather than different A records. The client MUST try the records in the order listed. The client only resolves the subsequent domain names if attempts to contact the first one failed or yielded no common transport protocols between client and server or denote a domain administratively prohibited by client policy. Use of multiple domain names is not meant to replace NAPTR (?TBD?) and SRV records, but rather to allow a single DHCP server to indicate LoST servers operated by multiple providers. wants to become something like this: The option MAY contain multiple domain names, each of which can separately be used to locate an appropriate LoST service as outlined in (). The client only resolves the subsequent domain names if attempts to contact the first one failed or yielded no common transport protocols between client and server or denote a domain administratively prohibited by client policy. And then this: Use of multiple domain names is not meant to replace NAPTR (?TBD?) and SRV records, but rather to allow a single DHCP server to indicate LoST servers operated by multiple providers. should actually be handled in the draft-ietf-ecrit-lost-01.txt document (IMO) -- an illustration of how you can use one FQDN and point to several different services operated by various providers. To borrow a text illustration from the S-NAPTR document, you already get at least 2 opportunities to "share the load" in ?-NAPTR: Thus, to find the EM services for thinkingcat.example, the NAPTR records for thinkingcat.example are retrieved: thinkingcat.example. ;; order pref flags IN NAPTR 100 10 "s" "EM:ProtA" ( ; service "" ; regexp _ProtA._tcp.thinkingcat.example. ; replacement ) IN NAPTR 100 20 "s" "EM:ProtB" ( ; service "" ; regexp _ProtB._tcp.example.com. ; replacement ) IN NAPTR 100 30 "s" "EM:ProtC" ( ; service "" ; regexp _ProtC._tcp.example.com. ; replacement ) Then the administrators at example.com can manage the preference rankings of the servers they use to support the ProtB service: _ProtB._tcp.example.com. ;; Pref Weight Port Target IN SRV 10 0 10001 bigiron.example.com. IN SRV 20 0 10001 backup.em.example.com. IN SRV 30 0 10001 nuclearfallout.australia-isp.example. Leslie. > > Ciao > Hannes > > Leslie Daigle schrieb: >> >> Further -- as noted in all the DDDS documentation, NAPTR >> records don't exist "in the wild"; they are always part of a >> DDDS application (in this case, U-NAPTR). >> >> So -- it seems that the 3rd option should really be about >> specifying the application unique string that feeds into >> the U-NAPTR-based LoST discovery specification. The >> application unique string would, in fact, be an FQDN. >> >> If you really need another layer of indirection (and I suspect >> Andy is right, you don't), you could still have multiple >> AUS's. >> >> Leslie. >> >> Andrew Newton wrote: >>> Hannes Tschofenig wrote: >>>> We used the procedure used in RFC 3361 and from RFC 3319. >>>> >>>> RFC 3361 >>>> Dynamic Host Configuration Protocol (DHCP-for-IPv4) >>>> Option for Session Initiation Protocol (SIP) Servers >>>> >>>> RFC 3319 >>>> >>>> Dynamic Host Configuration Protocol (DHCPv6) Options >>>> for Session Initiation Protocol (SIP) Servers >>> >>> Yes, it looks very similar. But the usages for SIP and LoST are very >>> different. The problem is that your LoST location configuration with >>> DHCP is actually non-interoperable with the current LoST specification. >>> >>> dhc-lost-discovery describes three methods of configuration: >>> >>> 1) IP address(es). >>> 2) A record lookup. >>> 3) Multiple NAPTR record lookups. >>> >>> The problem with the 1 and 2 is that they don't do enough. The >>> U-NAPTR resolution specified in LoST could, and likely should, result >>> in HTTP URIs that use ports other than 80 with specific query paths. >>> As an example: https://example.com:4433/lost/. Neither an IP address >>> nor an A record is enough information to construct that URI. >>> >>> The problem with option 3 is that it fails to understand how DNS and >>> U-NAPTR work. Your specification says that when multiple DNS qnames >>> are present, they are used to query multiple NAPTR records. Why? >>> The query against one qname can result in multiple NAPTR records. >>> What's the purpose of adding a layer above the U-NAPTR algorithm? >>> >>> I can only conclude that this draft is incompatible with the work >>> already accepted by ECRIT, and therefore should not be accepted as a >>> working group item until it is fixed. >>> >>> To be quite clear, I like the idea of using DHCP to configure a >>> pointer to the LoST server, and I'd be in favor of working group >>> acceptance of a document that did it in a way compatible with LoST. >>> >>> -andy >>> >> >> > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 26 19:35:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSMSc-0006pK-4X; Tue, 26 Sep 2006 19:35:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSMSb-0006pF-1y for ecrit@ietf.org; Tue, 26 Sep 2006 19:35:33 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSMSZ-00043w-Oo for ecrit@ietf.org; Tue, 26 Sep 2006 19:35:33 -0400 Received: from [192.168.0.109] ([::ffff:64.102.254.33]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Tue, 26 Sep 2006 19:35:07 -0400 id 015880F7.4519B92B.0000481D Message-ID: <4519B931.5060903@thinkingcat.com> Date: Tue, 26 Sep 2006 19:35:13 -0400 From: Leslie Daigle User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Ted Hardie , Andrew Newton , Henning Schulzrinne , "Tschofenig, Hannes" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: ECRIT Subject: [Ecrit] Some comments on draft-ietf-ecrit-lost-01.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'm not sure I'm tracking this section: > 4. Resolving Service URNs Using LoST > > If a LoST URL contains a host name rather than an IP address, clients > need to perform an U-NAPTR [17] lookup to obtain a DNS A record and > IP address. These records map the 'host' part of the LoST URL to one > or more URLs indicating the protocol to carry the LoST request. In > this document, only the HTTP and HTTPS URL schemes are defined. Note > that the HTTP URL can be any valid HTTP URL, including those > containing path elements. > > Here is an example: > > example.com. > > IN NAPTR 100 10 "u" "LoST:https" > "!*.!https://lostserver.example.com/secure!" "" > > IN NAPTR 200 10 "u" "LoST:http" > "!*.!http://lostserver.example.com!" "" > > The text talks about using U-NAPTR to get A record/IP addresses -- and yet the whole POINT of U-NAPTR is to allow the possibility of returning URIs, which is what the example shows, anyway..? And is that section title a carryover from a previous version, because I don't see how this has to do with Service URNs? So maybe that should be something like: 4. Resolving LoST URLs If a LoST URL contains a host name rather than an IP address, clients need to use U-NAPTR [17] using the U-NAPTR specification described below to obtain a URI (indicating host and protocol) for the applicable LoST service. In this document, only the HTTP and HTTPS URL schemes are defined. Note that the HTTP URL can be any valid HTTP URL, including those containing path elements. Here is an example: for lost:example.com example.com. IN NAPTR 100 10 "u" "LoST:https" "!*.!https://lostserver.example.com/secure!" "" IN NAPTR 200 10 "u" "LoST:http" "!*.!http://lostserver.example.com!" "" And then you'd need a separate section defining the U-NAPTR application (which application service(s) is(are) being defined or is(are) applicable, and ditto for application protocols). Then this section > 9. LoST Transport > > LoST needs an underlying protocol transport mechanisms to carry > requests and responses. This document defines the use of LoST over > HTTP and HTTP-over-TLS; other mechanisms are left to future > documents. The available transport mechanisms are indicated in the > LoST U-NAPTR DNS resource record. In protocols that support content > type indication, LoST uses the media type application/lost+xml. > > When using HTTP [14] and HTTP-over-TLS [15], LoST requests use the > HTTP POST method. All HTTP responses are applicable. The HTTP URL > is derived from the LoST URL via U-NAPTR translation, as discussed in > Section 4. needs some tweaking -- there is no such thing as a "LoST U-NAPTR DNS resource record". Perhaps, instead: 9. LoST Transport LoST needs an underlying protocol transport mechanisms to carry requests and responses. This document defines the use of LoST over HTTP and HTTP-over-TLS; other mechanisms are left to future documents. The available transport mechanisms are determined through the use of the LoST U-NAPTR application. In protocols that support content type indication, LoST uses the media type application/lost+xml. When using HTTP [14] and HTTP-over-TLS [15], LoST requests use the HTTP POST method. All HTTP responses are applicable. The HTTP URL is derived from the LoST URL via U-NAPTR application, as discussed in Section 4. And then I wondered if this reference was still right: > A LoST service may also be represented by multiple LoST servers, > either grouped together or at multiple network locations. Using > S-NAPTR [24], clients may be given a list of multiple servers to > which queries can be sent for a single service. I.e., is that still S-NAPTR, or is it now U-NAPTR, or? Leslie. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 26 20:14:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSN43-0005Z3-Ro; Tue, 26 Sep 2006 20:14:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSN42-0005Yq-Ve for ecrit@ietf.org; Tue, 26 Sep 2006 20:14:14 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSN41-0003jb-Gt for ecrit@ietf.org; Tue, 26 Sep 2006 20:14:14 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k8R0EBDf031300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 26 Sep 2006 17:14:12 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k8R0EAOn017797; Tue, 26 Sep 2006 17:14:11 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Sep 2006 17:14:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Indication of PSAP Confidence Level in a LoST Query Response Date: Tue, 26 Sep 2006 17:14:10 -0700 Message-ID: <21A52261514BE844AB662C1C21A29EA9289658@NAEX13.na.qualcomm.com> In-Reply-To: <4519AA1D.60803@nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Indication of PSAP Confidence Level in a LoST Query Response thread-index: AcbhvsNtPLow8gqtQS2Lzhod5+ngWQACmkcQ From: "Edge, Stephen" To: "Tom-PT Taylor" X-OriginalArrivalTime: 27 Sep 2006 00:14:11.0200 (UTC) FILETIME=[DB62D000:01C6E1C9] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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: , Errors-To: ecrit-bounces@ietf.org Hi Tom Thanks for the comment. Your assumption is correct - and applies to all positioning methods that I am aware of applicable to positioning of a terminal accessing a cellular wireless network (e.g. it applies to cell ID, enhanced cell ID, E-OTD, U-TDOA, A-FLT, OTDOA, GPS, A-GPS).=20 Kind Regards Stephen -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortel.com]=20 Sent: Tuesday, September 26, 2006 3:31 PM To: Edge, Stephen Cc: ecrit@ietf.org Subject: Re: [Ecrit] Indication of PSAP Confidence Level in a LoST Query Response Your proposal assumes knowledge of a probability distribution of the target's location over the surface of the earth (or perhaps within a volume over the surface of the earth. Is this reasonable, or capable of approximation? I suspect it is possible only for certain access methods. Edge, Stephen wrote: > Hi All >=20 > Here is a topic that may or may not be new but maybe not yet > presented in this light. In the not so distant future and certainly > within the possible lifetime of the LoST capability, it may be > possible using new algorithms and additional processing and storage > availability to determine the probability that a particular PSAP URI > is the correct one for a provided geographic or civil location > (taking account of the fact that any provided location will often > include, implicitly or explicitly, some area of uncertainty). This > capability is possible in principle even today; it is just that the > required amount of processing and storage may be too high (or the > ability of currently known algorithms too low) to allow realistic and > cost effective implementation. >=20 ... _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 26 21:29:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSOEl-0007iG-FT; Tue, 26 Sep 2006 21:29:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSOEk-0007iA-GT for ecrit@ietf.org; Tue, 26 Sep 2006 21:29:22 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSOEi-00018t-OF for ecrit@ietf.org; Tue, 26 Sep 2006 21:29:22 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k8R1Sp45008996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 26 Sep 2006 18:28:52 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k8R1Sout018132; Tue, 26 Sep 2006 18:28:51 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Sep 2006 18:28:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Indication of PSAP Confidence Level in a LoST QueryResponse Date: Tue, 26 Sep 2006 18:28:52 -0700 Message-ID: <21A52261514BE844AB662C1C21A29EA9289671@NAEX13.na.qualcomm.com> In-Reply-To: <08D4AFB5-4443-402D-844F-E42F5186EBD5@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Indication of PSAP Confidence Level in a LoST QueryResponse thread-index: Acbhglkt5Yo3fSmOSzKEWPdKBIZrjQAR8Yaw From: "Edge, Stephen" To: "Henning Schulzrinne" , "Brian Rosen" , "Thomson, Martin" X-OriginalArrivalTime: 27 Sep 2006 01:28:50.0922 (UTC) FILETIME=[498224A0:01C6E1D4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi All Thanks for the comments (Martin, Brian, Henning). Though not too encouraging so far, here are a few responses. Martin's comments: I am not proposing including confidence/probability information in the LoST query (just a geographic shape would do) although I believe it would help. My proposal is just to allow optional addition of a confidence value associated with a single PSAP URI result in the LoST response. That way the call server knows the likelihood of misrouting (e.g. in some cases could be 50% or higher). If it turns out that the chosen PSAP is not even E911 phase 2 capable, there could be a major problem in rerouting to the correct PSAP because the initially chosen PSAP will not be able to receive a more accurate location estimate. However, I agree that this proposed capability may not be very useful initially because servers may not support it and clients may not be adaptable enough to take advantage. However, that could change in a few years as algorithms get smarter. For example, it would probably be quite simple to perform some of the calculations in non-real time - e.g. associate each cell ID with a single PSAP URI and confidence level - and perform a simple lookup in real time. If the capability is not allowed, then it won't be possible (or at least not so straightforward) to improve call setup time and routing reliability - which would be a pity. Brian's comments: I agree that one input could be a hard edged polygon in which case (if a uniform probability distribution is assumed), the resulting confidence is just the proportional overlap with the PSAP coverage area. For some positioning methods (e.g. yielding other shapes), a probability distribution can be assumed in which case the calculation of the confidence would be more complex (but still possible). The LoST response can remain deterministic (assuming "perfect algorithms") as long as the allowed geographic shape inputs are defined carefully enough (e.g. state any default confidence level and/or probability distribution). This is not to say that different algorithms (or possibly even different implementations of the same algorithm) would always yield the same results - in fact, due to approximations, programming errors and shortcuts etc. they probably would not no matter how simple you make the protocol definition (e.g. consider a point input exactly on a PSAP boundary). Henning's comments: you seem to be saying that cell-sector based location estimates will typically cause routing errors whereas with more accurate (E911 phase 2 type) location, any routing error (considering that the terminal will be very close to the destination PSAP's coverage area) will not be important. I have a somewhat different view though based on similar premises. For a given geographic area location input L, consider 2 possible results: (a) L is within one PSAP's coverage area with a confidence level >=3DX (e.g. X =3D 90%); (b) L spans >=3D2 PSAP = areas with a confidence level I'm not sure I understand what you are proposing. The service =20 > boundaries > are hard edged polygons. If you put a point in, you get an exact =20 > answer > out. If you put a shape in, then we could have some kind of =20 > overlap of the > boundary polygons with the shape, and get uncertainty from that. =20 > Is that > what you were proposing? > > If so, I think I would support some kind of output that told you =20 > how close > of a fit we got. If that's not it, perhaps you would explain in =20 > more detail > what you propose. > > I do think we are pushing for the LoST resolver to be simple and > deterministic. The reason is that it is not in a position to =20 > understand > what the tradeoffs are. In general, the closer you get to the =20 > origin of the > location information, the more you understand what is actually =20 > happening on > the ground. We want earlier elements to make the decisions, and =20 > not later > elements. Thus we insist that if you have more than one location, the > client chooses, and not the server. If we force the client to =20 > interpret > inexactness, then I think giving it as much information to make the =20 > choice > as we can is a useful thing to do. > > Brian > >> -----Original Message----- >> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] >> Sent: Tuesday, September 26, 2006 2:58 AM >> To: Edge, Stephen; ecrit@ietf.org >> Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a LoST >> QueryResponse >> >> Hi Stephen, >> >> I must admit, that I can't see any tangible benefits for this =20 >> right now - >> that is probably going to be the biggest point leveled against this >> proposal. >> >> These sorts of discussion have been run in the past. Consider the >> discussions on whether or not uncertainty should be included in LoST >> (check the archives; it was in the last few weeks). And GEOPRIV have >> discussed confidence on the past, and aside from problems with people >> understanding the concepts, the main point against its inclusion =20 >> was the >> lack of perceived benefit. >> >> You are probably correct, in that we don't know today how we could =20 >> benefit >> from things like uncertainty and confidence in the future. =20 >> Certainly, >> there is wisdom in drawing a line and saying "Ware Ye, Here Be =20 >> Dragons". >> Even if you know that there are people living on the other side of =20 >> that >> line happily, you can get on with your business, which is engineering >> workable solutions. >> >> I suspect that this is primarily because people have trouble with the >> vagaries inherent in mobile and wireless systems. For LoST, in =20 >> the here >> and now, what you are asking for is a small change in the underlying >> philosophy. This philosophy isn't necessarily written down, but =20 >> you will >> find that this WG is currently operating under the assumption that =20 >> its >> inputs will be simple. This gives solid, repeatable results; you can >> write algorithms to that; and almost anyone can get it right. =20 >> Having one >> result is nice - we don't want request forking, which is a =20 >> possibility >> unless you have a clear one-to-one mapping from location to URI... >> >> location -> FG -> FG (-> FG ...) -> Tree -> URI >> >> You understand the vagaries, and are comfortable with them, but these >> scare the willies out of most people - because you don't get =20 >> results in >> nice tidy boxes. It's also harder to design a system that deals with >> fuzzy inputs. To start with, you need a really compelling reason =20 >> to do >> it. Then, you need to make it so easy to do that not doing it =20 >> would seem >> recalcitrant. >> >> I personally like the idea of building in a little tolerance into the >> whole system. And being able to convey this sort of information =20 >> could be >> useful outside of an emergency situation as a sort of tuning =20 >> mechanism. >> Certainly, it would be useful in combination with location =20 >> uncertainty and >> confidence to know whether or not current location information is >> adequate. >> >> But this is from the person that reminded GEOPRIV that location isn't >> always a simple point in space. >> >> Cheers, >> Martin >> >> ________________________________________ >> From: Edge, Stephen [mailto:sedge@qualcomm.com] >> Sent: Tuesday, 26 September 2006 2:36 PM >> To: ecrit@ietf.org >> Subject: [Ecrit] Indication of PSAP Confidence Level in a LoST Query >> Response >> >> Hi All >> Here is a topic that may or may not be new but maybe not yet =20 >> presented in >> this light. In the not so distant future and certainly within the =20 >> possible >> lifetime of the LoST capability, it may be possible using new =20 >> algorithms >> and additional processing and storage availability to determine the >> probability that a particular PSAP URI is the correct one for a =20 >> provided >> geographic or civil location (taking account of the fact that any =20 >> provided >> location will often include, implicitly or explicitly, some area of >> uncertainty). This capability is possible in principle even today; =20 >> it is >> just that the required amount of processing and storage may be too =20 >> high >> (or the ability of currently known algorithms too low) to allow =20 >> realistic >> and cost effective implementation. >> >> Assuming that a probability value, AKA confidence level, was =20 >> provided in a >> LoST response, it would be possible with some solutions being =20 >> developed >> (e.g. 3GPP and maybe 3GPP2) to obtain a more exact location for a =20 >> wireless >> (or maybe wireline) user if the confidence value was not high and no >> significant delay had yet been expended to obtain the initial =20 >> location. >> That would then allow a second LoST query with a higher =20 >> probability of >> success. It would also permit a network to instigate the initial LoST >> query using simple location information such as cell ID requiring =20 >> no time >> to obtain. The overall result could be significantly lower call delay >> wherever an initial location mapped unambiguously to a single PSAP =20 >> URI and >> more reliable routing for callers in PSAP border areas. >> >> This capability may seem strange in a wireline environment where a >> terminal would typically stay put for extended periods of time =20 >> allowing >> plenty of opportunity to obtain a location before an emergency =20 >> call was >> originated. But in a wireless environment, it can be practically >> impossible to know location with anything but very coarse accuracy =20 >> at any >> arbitrary point in time and the time needed to obtain a location more >> accurately can be significant. It should also be noted that such an >> enhancement to LoST could be mostly independent of the means used to >> obtain location (whether for the first or second query). In other =20 >> words, >> such a capability need not (greatly) prejudice issues relating to the >> architecture, procedures and methods used to obtain location. >> >> Of course, such an enhancement to LoST might be added later after =20 >> it was >> well established that algorithms and computational capability =20 >> would be up >> to the task. But the addition of an extra optional parameter to a =20 >> LoST >> response need not impact implementations that choose not to use it =20 >> (either >> as a client or server). And later implementation support would be =20 >> easier >> because it would not require any new standards change. (Of course, >> proprietary support would always be possible, but potentially =20 >> dangerous >> because of the risk of LoST evolution in some other direction, =20 >> such as >> provision of more than one PSAP URI.) >> >> One possible consequence of this proposal might be to encourage non- >> uniformity in the algorithms used to convert location to PSAP URI - >> meaning different implementations could occasionally deliver =20 >> different >> URIs (and different confidence levels) for the same location input =20 >> and >> same PSAP database map. But I wonder if this should really be an =20 >> issue - >> e.g. it may well turn out that some algorithms are better (more =20 >> reliable, >> faster etc.) than others and that a demonstration of this in a live >> environment would be a good way to ensure that the better ones =20 >> eventually >> become the ones most widely adopted. >> >> Anyhow, please comment on this. >> Kind Regards >> Stephen >> --------------------------------------------------------------------- >> ----- >> ---------------------- >> This message is for the designated recipient only and may >> contain privileged, proprietary, or otherwise private information. >> If you have received it in error, please notify the sender >> immediately and delete the original. Any unauthorized use of >> this email is prohibited. >> --------------------------------------------------------------------- >> ----- >> ---------------------- >> [mf2] > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 26 21:52:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSOb5-0004oI-Fi; Tue, 26 Sep 2006 21:52:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSOb4-0004nS-9Z for ecrit@ietf.org; Tue, 26 Sep 2006 21:52:26 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSOb3-0003cH-LQ for ecrit@ietf.org; Tue, 26 Sep 2006 21:52:26 -0400 Received: from [192.168.0.41] (pool-141-153-175-20.mad.east.verizon.net [141.153.175.20]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k8R1puu9027836 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Tue, 26 Sep 2006 21:51:57 -0400 (EDT) In-Reply-To: <21A52261514BE844AB662C1C21A29EA9289671@NAEX13.na.qualcomm.com> References: <21A52261514BE844AB662C1C21A29EA9289671@NAEX13.na.qualcomm.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <25369886-398B-4E90-A13A-CB9CE26082A1@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Indication of PSAP Confidence Level in a LoST QueryResponse Date: Tue, 26 Sep 2006 21:51:49 -0400 To: "Edge, Stephen" X-Mailer: Apple Mail (2.752.2) X-PerlMx-Spam: Gauge=XXII, Probability=22%, X-Seen-By filter1.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: bfef20db74c24e87b6dbcd42ea7ba67c Cc: ECRIT , "Thomson, Martin" 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: , Errors-To: ecrit-bounces@ietf.org Stephen, any engineering is a trade-off between functionality and complexity. Speaking from some experience, I so far have always regretted when erring on the side of complexity, on the "it could be useful" theory. I have no intention of repeating this mistake for LoST, particularly for a truly mission-critical system. You probably would want to review the list discussion as to why I believe any marginal increase in "correct" routing is just not worth the tremendous cost in overall system complexity and unpredictability. I won't bore the rest of the list by repeating these. I just don't see cell sector as useful, long term, so whether it could actually work in some large number of cases is rather immaterial. Since we know that it will fail, regardless of probability routing or not, in an unacceptably large number of cases, it seems much better to design a system that actually works, particularly given that the technology is available and now standard on most modern cell phones. Old cell phone systems won't be running LoST anyway. I have to admit that I find it rather uninteresting whether I call the wrong PSAP if I'm 100 ft from the border of the PSAP. You'll always have cases where the initial route goes to PSAP A, but the caller moves to PSAP B while talking to the call taker. In the town I live, it probably takes about 2 minutes, at 30 mph, to cross the PSAP coverage area. Within that range, I'm also just as likely to report on an incident on the other side of the town border. Again, lots of complexity for no operational gain. While it is theoretically possible, with some very low probability, to end up exactly on the border between two PSAPs, in that case, it just doesn't matter what happens and whether two implementations do the same thing. By definition, either PSAP is as good the other. In those rare cases where the client cares, it can do the probabilistic computation. I'd rather have those that care, pay the cost, rather than everyone. Henning On Sep 26, 2006, at 9:28 PM, Edge, Stephen wrote: > Hi All > > Thanks for the comments (Martin, Brian, Henning). Though not too > encouraging so far, here are a few responses. > > Martin's comments: I am not proposing including confidence/probability > information in the LoST query (just a geographic shape would do) > although I believe it would help. My proposal is just to allow > optional > addition of a confidence value associated with a single PSAP URI > result > in the LoST response. That way the call server knows the likelihood of > misrouting (e.g. in some cases could be 50% or higher). If it turns > out > that the chosen PSAP is not even E911 phase 2 capable, there could > be a > major problem in rerouting to the correct PSAP because the initially > chosen PSAP will not be able to receive a more accurate location > estimate. However, I agree that this proposed capability may not be > very > useful initially because servers may not support it and clients may > not > be adaptable enough to take advantage. However, that could change in a > few years as algorithms get smarter. For example, it would probably be > quite simple to perform some of the calculations in non-real time - > e.g. > associate each cell ID with a single PSAP URI and confidence level > - and > perform a simple lookup in real time. If the capability is not > allowed, > then it won't be possible (or at least not so straightforward) to > improve call setup time and routing reliability - which would be a > pity. > > Brian's comments: I agree that one input could be a hard edged polygon > in which case (if a uniform probability distribution is assumed), the > resulting confidence is just the proportional overlap with the PSAP > coverage area. For some positioning methods (e.g. yielding other > shapes), a probability distribution can be assumed in which case the > calculation of the confidence would be more complex (but still > possible). The LoST response can remain deterministic (assuming > "perfect > algorithms") as long as the allowed geographic shape inputs are > defined > carefully enough (e.g. state any default confidence level and/or > probability distribution). This is not to say that different > algorithms > (or possibly even different implementations of the same algorithm) > would > always yield the same results - in fact, due to approximations, > programming errors and shortcuts etc. they probably would not no > matter > how simple you make the protocol definition (e.g. consider a point > input > exactly on a PSAP boundary). > > Henning's comments: you seem to be saying that cell-sector based > location estimates will typically cause routing errors whereas with > more > accurate (E911 phase 2 type) location, any routing error (considering > that the terminal will be very close to the destination PSAP's > coverage > area) will not be important. I have a somewhat different view though > based on similar premises. For a given geographic area location > input L, > consider 2 possible results: (a) L is within one PSAP's coverage area > with a confidence level >=X (e.g. X = 90%); (b) L spans >=2 PSAP areas > with a confidence level significant > frequency when L is cell-sector based (which I would find hard to > doubt > given the large numbers of small urban cells and some large PSAP > coverage areas), then using cell-sector as an initial input could be > sensible. For (b), there may be value in obtaining more accurate > location information because the smaller the size of L, the higher > will > be the incidence of (a). (b) will still occur sometimes no matter how > small L becomes (unless a point), but then the argument that any > resulting routing error is less important comes to the rescue and you > end up with a methodology that can both reduce call delay and improve > routing reliability. (Note concerning Monte Carlo sampling by the > client: I agree that is one solution but rather inefficient, also > complex for the client.) > > I look forward to more comments which hopefully can progress this. > > Kind Regards > > Stephen > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, September 26, 2006 5:26 AM > To: Brian Rosen > Cc: Edge, Stephen; ECRIT > Subject: Re: [Ecrit] Indication of PSAP Confidence Level in a LoST > QueryResponse > > I'll also add that earlier discussion has yielded the insight that > sector-size areas are pretty useless for call routing, as there is a > significant probability of mis-routes. > > This probability won't be reduced all that much by fancy area > maximization techniques or anything else since you simply can't tell > which of the PSAP serving areas you're in. With area maximization, > for example, users in a cell sector will simply be assigned to > whatever PSAP service area dominates the cell sector. On average, > across cell towers, that will still make it a 50/50 toss-up. > > For dispatch, mid-sized areas of uncertainty are useful, > corresponding to the typical FCC-compliant uncertainty regions of a > few hundred feet. However, worrying that such areas span multiple > PSAPs and then trying to pick the right one seems rather pointless > (sorry...), given the complexity. (If clients really care, they can > randomly sample the area, essentially doing a Monte-Carlo simulation, > which will yield an area maximization by design.) > > Thus, I just don't see the benefit. Either the area of uncertainty is > too large for routing, as it is for tower/face information, or it is > too small to worry about the right PSAP, and can be treated as a > point for PSAP selection purposes. > > > Henning > > On Sep 26, 2006, at 7:28 AM, Brian Rosen wrote: > >> I'm not sure I understand what you are proposing. The service >> boundaries >> are hard edged polygons. If you put a point in, you get an exact >> answer >> out. If you put a shape in, then we could have some kind of >> overlap of the >> boundary polygons with the shape, and get uncertainty from that. >> Is that >> what you were proposing? >> >> If so, I think I would support some kind of output that told you >> how close >> of a fit we got. If that's not it, perhaps you would explain in >> more detail >> what you propose. >> >> I do think we are pushing for the LoST resolver to be simple and >> deterministic. The reason is that it is not in a position to >> understand >> what the tradeoffs are. In general, the closer you get to the >> origin of the >> location information, the more you understand what is actually >> happening on >> the ground. We want earlier elements to make the decisions, and >> not later >> elements. Thus we insist that if you have more than one location, >> the >> client chooses, and not the server. If we force the client to >> interpret >> inexactness, then I think giving it as much information to make the >> choice >> as we can is a useful thing to do. >> >> Brian >> >>> -----Original Message----- >>> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] >>> Sent: Tuesday, September 26, 2006 2:58 AM >>> To: Edge, Stephen; ecrit@ietf.org >>> Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a LoST >>> QueryResponse >>> >>> Hi Stephen, >>> >>> I must admit, that I can't see any tangible benefits for this >>> right now - >>> that is probably going to be the biggest point leveled against this >>> proposal. >>> >>> These sorts of discussion have been run in the past. Consider the >>> discussions on whether or not uncertainty should be included in LoST >>> (check the archives; it was in the last few weeks). And GEOPRIV >>> have >>> discussed confidence on the past, and aside from problems with >>> people >>> understanding the concepts, the main point against its inclusion >>> was the >>> lack of perceived benefit. >>> >>> You are probably correct, in that we don't know today how we could >>> benefit >>> from things like uncertainty and confidence in the future. >>> Certainly, >>> there is wisdom in drawing a line and saying "Ware Ye, Here Be >>> Dragons". >>> Even if you know that there are people living on the other side of >>> that >>> line happily, you can get on with your business, which is >>> engineering >>> workable solutions. >>> >>> I suspect that this is primarily because people have trouble with >>> the >>> vagaries inherent in mobile and wireless systems. For LoST, in >>> the here >>> and now, what you are asking for is a small change in the underlying >>> philosophy. This philosophy isn't necessarily written down, but >>> you will >>> find that this WG is currently operating under the assumption that >>> its >>> inputs will be simple. This gives solid, repeatable results; you >>> can >>> write algorithms to that; and almost anyone can get it right. >>> Having one >>> result is nice - we don't want request forking, which is a >>> possibility >>> unless you have a clear one-to-one mapping from location to URI... >>> >>> location -> FG -> FG (-> FG ...) -> Tree -> URI >>> >>> You understand the vagaries, and are comfortable with them, but >>> these >>> scare the willies out of most people - because you don't get >>> results in >>> nice tidy boxes. It's also harder to design a system that deals >>> with >>> fuzzy inputs. To start with, you need a really compelling reason >>> to do >>> it. Then, you need to make it so easy to do that not doing it >>> would seem >>> recalcitrant. >>> >>> I personally like the idea of building in a little tolerance into >>> the >>> whole system. And being able to convey this sort of information >>> could be >>> useful outside of an emergency situation as a sort of tuning >>> mechanism. >>> Certainly, it would be useful in combination with location >>> uncertainty and >>> confidence to know whether or not current location information is >>> adequate. >>> >>> But this is from the person that reminded GEOPRIV that location >>> isn't >>> always a simple point in space. >>> >>> Cheers, >>> Martin >>> >>> ________________________________________ >>> From: Edge, Stephen [mailto:sedge@qualcomm.com] >>> Sent: Tuesday, 26 September 2006 2:36 PM >>> To: ecrit@ietf.org >>> Subject: [Ecrit] Indication of PSAP Confidence Level in a LoST Query >>> Response >>> >>> Hi All >>> Here is a topic that may or may not be new but maybe not yet >>> presented in >>> this light. In the not so distant future and certainly within the >>> possible >>> lifetime of the LoST capability, it may be possible using new >>> algorithms >>> and additional processing and storage availability to determine the >>> probability that a particular PSAP URI is the correct one for a >>> provided >>> geographic or civil location (taking account of the fact that any >>> provided >>> location will often include, implicitly or explicitly, some area of >>> uncertainty). This capability is possible in principle even today; >>> it is >>> just that the required amount of processing and storage may be too >>> high >>> (or the ability of currently known algorithms too low) to allow >>> realistic >>> and cost effective implementation. >>> >>> Assuming that a probability value, AKA confidence level, was >>> provided in a >>> LoST response, it would be possible with some solutions being >>> developed >>> (e.g. 3GPP and maybe 3GPP2) to obtain a more exact location for a >>> wireless >>> (or maybe wireline) user if the confidence value was not high and no >>> significant delay had yet been expended to obtain the initial >>> location. >>> That would then allow a second LoST query with a higher >>> probability of >>> success. It would also permit a network to instigate the initial >>> LoST >>> query using simple location information such as cell ID requiring >>> no time >>> to obtain. The overall result could be significantly lower call >>> delay >>> wherever an initial location mapped unambiguously to a single PSAP >>> URI and >>> more reliable routing for callers in PSAP border areas. >>> >>> This capability may seem strange in a wireline environment where a >>> terminal would typically stay put for extended periods of time >>> allowing >>> plenty of opportunity to obtain a location before an emergency >>> call was >>> originated. But in a wireless environment, it can be practically >>> impossible to know location with anything but very coarse accuracy >>> at any >>> arbitrary point in time and the time needed to obtain a location >>> more >>> accurately can be significant. It should also be noted that such an >>> enhancement to LoST could be mostly independent of the means used to >>> obtain location (whether for the first or second query). In other >>> words, >>> such a capability need not (greatly) prejudice issues relating to >>> the >>> architecture, procedures and methods used to obtain location. >>> >>> Of course, such an enhancement to LoST might be added later after >>> it was >>> well established that algorithms and computational capability >>> would be up >>> to the task. But the addition of an extra optional parameter to a >>> LoST >>> response need not impact implementations that choose not to use it >>> (either >>> as a client or server). And later implementation support would be >>> easier >>> because it would not require any new standards change. (Of course, >>> proprietary support would always be possible, but potentially >>> dangerous >>> because of the risk of LoST evolution in some other direction, >>> such as >>> provision of more than one PSAP URI.) >>> >>> One possible consequence of this proposal might be to encourage non- >>> uniformity in the algorithms used to convert location to PSAP URI - >>> meaning different implementations could occasionally deliver >>> different >>> URIs (and different confidence levels) for the same location input >>> and >>> same PSAP database map. But I wonder if this should really be an >>> issue - >>> e.g. it may well turn out that some algorithms are better (more >>> reliable, >>> faster etc.) than others and that a demonstration of this in a live >>> environment would be a good way to ensure that the better ones >>> eventually >>> become the ones most widely adopted. >>> >>> Anyhow, please comment on this. >>> Kind Regards >>> Stephen >>> -------------------------------------------------------------------- >>> - > >>> ----- >>> ---------------------- >>> This message is for the designated recipient only and may >>> contain privileged, proprietary, or otherwise private information. >>> If you have received it in error, please notify the sender >>> immediately and delete the original. Any unauthorized use of >>> this email is prohibited. >>> -------------------------------------------------------------------- >>> - > >>> ----- >>> ---------------------- >>> [mf2] >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 26 21:55:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSOdz-0006sc-11; Tue, 26 Sep 2006 21:55:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSOdw-0006nd-W6 for ecrit@ietf.org; Tue, 26 Sep 2006 21:55:24 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSOdv-0003ya-NY for ecrit@ietf.org; Tue, 26 Sep 2006 21:55:24 -0400 Received: from [192.168.0.41] (pool-141-153-175-20.mad.east.verizon.net [141.153.175.20]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k8R1t8u9028045 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Tue, 26 Sep 2006 21:55:09 -0400 (EDT) In-Reply-To: <4519B931.5060903@thinkingcat.com> References: <4519B931.5060903@thinkingcat.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Date: Tue, 26 Sep 2006 21:55:01 -0400 To: Leslie Daigle X-Mailer: Apple Mail (2.752.2) X-PerlMx-Spam: Gauge=XXII, Probability=22%, X-Seen-By filter1.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ECRIT Subject: [Ecrit] Re: Some comments on draft-ietf-ecrit-lost-01.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > The text talks about using U-NAPTR to get A record/IP addresses -- > and yet the whole POINT of U-NAPTR is to allow the possibility > of returning URIs, which is what the example shows, anyway..? > Indeed; the section was hastily cut-and-pasted, and thus is best taken with a large grain of salt. > And is that section title a carryover from a previous version, > because I don't see how this has to do with Service URNs? > > So maybe that should be something like: > > 4. Resolving LoST URLs > > If a LoST URL contains a host name rather than an IP address, > clients > need to use U-NAPTR [17] using the U-NAPTR specification > described below to obtain a URI (indicating host and protocol) > for the applicable LoST service. In > this document, only the HTTP and HTTPS URL schemes are defined. > Note > that the HTTP URL can be any valid HTTP URL, including those > containing path elements. > > Here is an example: for lost:example.com > > example.com. > > IN NAPTR 100 10 "u" "LoST:https" > "!*.!https://lostserver.example.com/secure!" "" > > IN NAPTR 200 10 "u" "LoST:http" > "!*.!http://lostserver.example.com!" "" > > > > And then you'd need a separate section defining the U-NAPTR > application > (which application service(s) is(are) being defined or is(are) > applicable, and ditto for application protocols). Agreed. > > 9. LoST Transport > > LoST needs an underlying protocol transport mechanisms to carry > requests and responses. This document defines the use of LoST over > HTTP and HTTP-over-TLS; other mechanisms are left to future > documents. The available transport mechanisms are determined > through the use of the LoST U-NAPTR application. In protocols > that support content > type indication, LoST uses the media type application/lost+xml. > > When using HTTP [14] and HTTP-over-TLS [15], LoST requests use the > HTTP POST method. All HTTP responses are applicable. The HTTP URL > is derived from the LoST URL via U-NAPTR application, as > discussed in > Section 4. This is indeed more precise. > > > > > And then I wondered if this reference was still right: > >> A LoST service may also be represented by multiple LoST servers, >> either grouped together or at multiple network locations. Using >> S-NAPTR [24], clients may be given a list of multiple servers to >> which queries can be sent for a single service. > > > > I.e., is that still S-NAPTR, or is it now U-NAPTR, or? That whole section is obsolete. I've given Hannes a set of edits that get rid of it. > > > > Leslie. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 26 22:06:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSOoG-00025m-BL; Tue, 26 Sep 2006 22:06:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSOoF-00025h-76 for ecrit@ietf.org; Tue, 26 Sep 2006 22:06:03 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSOoD-000510-VK for ecrit@ietf.org; Tue, 26 Sep 2006 22:06:03 -0400 Received: from [192.168.0.41] (pool-141-153-175-20.mad.east.verizon.net [141.153.175.20]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k8R25uu9028740 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Tue, 26 Sep 2006 22:06:00 -0400 (EDT) In-Reply-To: <25369886-398B-4E90-A13A-CB9CE26082A1@cs.columbia.edu> References: <21A52261514BE844AB662C1C21A29EA9289671@NAEX13.na.qualcomm.com> <25369886-398B-4E90-A13A-CB9CE26082A1@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <59F7CDBC-8373-401E-86ED-6B6FD800DA38@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Indication of PSAP Confidence Level in a LoST QueryResponse Date: Tue, 26 Sep 2006 22:05:49 -0400 To: Stephen Edge X-Mailer: Apple Mail (2.752.2) X-PerlMx-Spam: Gauge=XXII, Probability=22%, X-Seen-By filter1.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > Another thought on that particular issue: > In those rare cases where the client cares, it can do the > probabilistic computation. I'd rather have those that care, pay the > cost, rather than everyone. This actually doesn't require Monte Carlo sampling, as I first surmised. The client only has to do the following: (1) Get the centroid of the polygon. Get the mapping, which will return a PSAP and a service area. (2) Compare the service region to the uncertainty region. If the service area covers more than 50% of the uncertainty region, you're done. This should be the most common case, as it is rather unlikely that the centroid is not in that area. (3) If not, pick a point that is just outside the service area, and repeat (1). Again, I don't recommend this, as the value is low, but it allows the client to do whatever fancy computation it wants, using all information at its disposal, including non-uniform probability maps, tarot cards and Ouija boards, without making the LoST infrastructure more complicated. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 27 00:45:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSRIO-00077Z-PJ; Wed, 27 Sep 2006 00:45:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSRIN-000768-4v for ecrit@ietf.org; Wed, 27 Sep 2006 00:45:19 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSRBp-0001IE-Om for ecrit@ietf.org; Wed, 27 Sep 2006 00:38:35 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k8R4cHaw009006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 26 Sep 2006 21:38:18 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k8R4cGRT004679; Tue, 26 Sep 2006 21:38:17 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Sep 2006 21:38:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Indication of PSAP Confidence Level in a LoST QueryResponse Date: Tue, 26 Sep 2006 21:38:14 -0700 Message-ID: <21A52261514BE844AB662C1C21A29EA928967A@NAEX13.na.qualcomm.com> In-Reply-To: <25369886-398B-4E90-A13A-CB9CE26082A1@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Indication of PSAP Confidence Level in a LoST QueryResponse thread-index: Acbh16UKFMGg2o6IR+iaxBlT2KdcAwACn8oQ From: "Edge, Stephen" To: "Henning Schulzrinne" X-OriginalArrivalTime: 27 Sep 2006 04:38:16.0663 (UTC) FILETIME=[C0049670:01C6E1EE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 94902b99ee6852833c9a2b680a1de4d3 Cc: ECRIT , "Thomson, Martin" 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: , Errors-To: ecrit-bounces@ietf.org Hi Henning Thanks for the further comments. I appreciate the points you are making. For many wireless networks (e.g. 3GPP UMTS, cdma2000), a cell-sector ID is all the network may generally receive from a terminal inside a SIP INVITE - since any more accurate location may cost too much in time (e.g. might not be associated by the network with an emergency call and hence not assigned priority status). With the 3GPP current architecture (3GPP2 has not yet decided one), this will be passed to an E-CSCF in the serving network and thence to an LRF (Location Retrieval Function) for use in deriving the PSAP URI. The LRF may be able to instigate more accurate location (e.g. using a user plane location solution like SUPL or using the 3GPP control plane solution) but this will take time and resources. If it turns out that the cell-sector ID maps to a PSAP URI with high confidence in a majority of cases, there would seem to be some benefit in performing this mapping rather than adding extra delay by attempting to obtain a more accurate location. Note that this is now an issue of call delay just as much as routing reliability which may be significant so long as legacy PSAPs have to be supported and there is delay on both the packet and circuit mode sides as well as in providing the interworking. I should also point out that the proposed capability is generally not possible for circuit mode wireless calls because the control points for location and routing are separate. Using the same control point for both functions allows an improvement (in terms of resource efficiency, call delay and routing reliability) over circuit mode that could provide a better service. I agree that removing unnecessary complexity from the service and server is worthwhile but I am not sure that an optional capability that can be omitted initially should count very heavily. For example, it is possible that algorithms that reliably deliver the most probable PSAP destination (I mean the truly most probable one and not an approximation based on centroids or other approximate data) will need the capability to compute some confidence measure anyway as part of the selection process. I suppose one conclusion of this discussion (given the direction in which it seems headed) would be to leave out this capability initially and then, based on actual call delay and routing results, reconsider it or something similar later if needed. Kind Regards Stephen -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Tuesday, September 26, 2006 6:52 PM To: Edge, Stephen Cc: Brian Rosen; Thomson, Martin; ECRIT Subject: Re: [Ecrit] Indication of PSAP Confidence Level in a LoST QueryResponse Stephen, any engineering is a trade-off between functionality and complexity. =20 Speaking from some experience, I so far have always regretted when =20 erring on the side of complexity, on the "it could be useful" theory. =20 I have no intention of repeating this mistake for LoST, particularly =20 for a truly mission-critical system. You probably would want to review the list discussion as to why I =20 believe any marginal increase in "correct" routing is just not worth =20 the tremendous cost in overall system complexity and =20 unpredictability. I won't bore the rest of the list by repeating these. I just don't see cell sector as useful, long term, so whether it =20 could actually work in some large number of cases is rather =20 immaterial. Since we know that it will fail, regardless of =20 probability routing or not, in an unacceptably large number of cases, =20 it seems much better to design a system that actually works, =20 particularly given that the technology is available and now standard =20 on most modern cell phones. Old cell phone systems won't be running =20 LoST anyway. I have to admit that I find it rather uninteresting whether I call =20 the wrong PSAP if I'm 100 ft from the border of the PSAP. You'll =20 always have cases where the initial route goes to PSAP A, but the =20 caller moves to PSAP B while talking to the call taker. In the town I =20 live, it probably takes about 2 minutes, at 30 mph, to cross the PSAP =20 coverage area. Within that range, I'm also just as likely to report =20 on an incident on the other side of the town border. Again, lots of =20 complexity for no operational gain. While it is theoretically possible, with some very low probability, =20 to end up exactly on the border between two PSAPs, in that case, it =20 just doesn't matter what happens and whether two implementations do =20 the same thing. By definition, either PSAP is as good the other. In those rare cases where the client cares, it can do the =20 probabilistic computation. I'd rather have those that care, pay the =20 cost, rather than everyone. Henning On Sep 26, 2006, at 9:28 PM, Edge, Stephen wrote: > Hi All > > Thanks for the comments (Martin, Brian, Henning). Though not too > encouraging so far, here are a few responses. > > Martin's comments: I am not proposing including confidence/probability > information in the LoST query (just a geographic shape would do) > although I believe it would help. My proposal is just to allow =20 > optional > addition of a confidence value associated with a single PSAP URI =20 > result > in the LoST response. That way the call server knows the likelihood of > misrouting (e.g. in some cases could be 50% or higher). If it turns =20 > out > that the chosen PSAP is not even E911 phase 2 capable, there could =20 > be a > major problem in rerouting to the correct PSAP because the initially > chosen PSAP will not be able to receive a more accurate location > estimate. However, I agree that this proposed capability may not be =20 > very > useful initially because servers may not support it and clients may =20 > not > be adaptable enough to take advantage. However, that could change in a > few years as algorithms get smarter. For example, it would probably be > quite simple to perform some of the calculations in non-real time - =20 > e.g. > associate each cell ID with a single PSAP URI and confidence level =20 > - and > perform a simple lookup in real time. If the capability is not =20 > allowed, > then it won't be possible (or at least not so straightforward) to > improve call setup time and routing reliability - which would be a =20 > pity. > > Brian's comments: I agree that one input could be a hard edged polygon > in which case (if a uniform probability distribution is assumed), the > resulting confidence is just the proportional overlap with the PSAP > coverage area. For some positioning methods (e.g. yielding other > shapes), a probability distribution can be assumed in which case the > calculation of the confidence would be more complex (but still > possible). The LoST response can remain deterministic (assuming =20 > "perfect > algorithms") as long as the allowed geographic shape inputs are =20 > defined > carefully enough (e.g. state any default confidence level and/or > probability distribution). This is not to say that different =20 > algorithms > (or possibly even different implementations of the same algorithm) =20 > would > always yield the same results - in fact, due to approximations, > programming errors and shortcuts etc. they probably would not no =20 > matter > how simple you make the protocol definition (e.g. consider a point =20 > input > exactly on a PSAP boundary). > > Henning's comments: you seem to be saying that cell-sector based > location estimates will typically cause routing errors whereas with =20 > more > accurate (E911 phase 2 type) location, any routing error (considering > that the terminal will be very close to the destination PSAP's =20 > coverage > area) will not be important. I have a somewhat different view though > based on similar premises. For a given geographic area location =20 > input L, > consider 2 possible results: (a) L is within one PSAP's coverage area > with a confidence level >=3DX (e.g. X =3D 90%); (b) L spans >=3D2 PSAP = areas > with a confidence level significant > frequency when L is cell-sector based (which I would find hard to =20 > doubt > given the large numbers of small urban cells and some large PSAP > coverage areas), then using cell-sector as an initial input could be > sensible. For (b), there may be value in obtaining more accurate > location information because the smaller the size of L, the higher =20 > will > be the incidence of (a). (b) will still occur sometimes no matter how > small L becomes (unless a point), but then the argument that any > resulting routing error is less important comes to the rescue and you > end up with a methodology that can both reduce call delay and improve > routing reliability. (Note concerning Monte Carlo sampling by the > client: I agree that is one solution but rather inefficient, also > complex for the client.) > > I look forward to more comments which hopefully can progress this. > > Kind Regards > > Stephen > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, September 26, 2006 5:26 AM > To: Brian Rosen > Cc: Edge, Stephen; ECRIT > Subject: Re: [Ecrit] Indication of PSAP Confidence Level in a LoST > QueryResponse > > I'll also add that earlier discussion has yielded the insight that > sector-size areas are pretty useless for call routing, as there is a > significant probability of mis-routes. > > This probability won't be reduced all that much by fancy area > maximization techniques or anything else since you simply can't tell > which of the PSAP serving areas you're in. With area maximization, > for example, users in a cell sector will simply be assigned to > whatever PSAP service area dominates the cell sector. On average, > across cell towers, that will still make it a 50/50 toss-up. > > For dispatch, mid-sized areas of uncertainty are useful, > corresponding to the typical FCC-compliant uncertainty regions of a > few hundred feet. However, worrying that such areas span multiple > PSAPs and then trying to pick the right one seems rather pointless > (sorry...), given the complexity. (If clients really care, they can > randomly sample the area, essentially doing a Monte-Carlo simulation, > which will yield an area maximization by design.) > > Thus, I just don't see the benefit. Either the area of uncertainty is > too large for routing, as it is for tower/face information, or it is > too small to worry about the right PSAP, and can be treated as a > point for PSAP selection purposes. > > > Henning > > On Sep 26, 2006, at 7:28 AM, Brian Rosen wrote: > >> I'm not sure I understand what you are proposing. The service >> boundaries >> are hard edged polygons. If you put a point in, you get an exact >> answer >> out. If you put a shape in, then we could have some kind of >> overlap of the >> boundary polygons with the shape, and get uncertainty from that. >> Is that >> what you were proposing? >> >> If so, I think I would support some kind of output that told you >> how close >> of a fit we got. If that's not it, perhaps you would explain in >> more detail >> what you propose. >> >> I do think we are pushing for the LoST resolver to be simple and >> deterministic. The reason is that it is not in a position to >> understand >> what the tradeoffs are. In general, the closer you get to the >> origin of the >> location information, the more you understand what is actually >> happening on >> the ground. We want earlier elements to make the decisions, and >> not later >> elements. Thus we insist that if you have more than one location, =20 >> the >> client chooses, and not the server. If we force the client to >> interpret >> inexactness, then I think giving it as much information to make the >> choice >> as we can is a useful thing to do. >> >> Brian >> >>> -----Original Message----- >>> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] >>> Sent: Tuesday, September 26, 2006 2:58 AM >>> To: Edge, Stephen; ecrit@ietf.org >>> Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a LoST >>> QueryResponse >>> >>> Hi Stephen, >>> >>> I must admit, that I can't see any tangible benefits for this >>> right now - >>> that is probably going to be the biggest point leveled against this >>> proposal. >>> >>> These sorts of discussion have been run in the past. Consider the >>> discussions on whether or not uncertainty should be included in LoST >>> (check the archives; it was in the last few weeks). And GEOPRIV =20 >>> have >>> discussed confidence on the past, and aside from problems with =20 >>> people >>> understanding the concepts, the main point against its inclusion >>> was the >>> lack of perceived benefit. >>> >>> You are probably correct, in that we don't know today how we could >>> benefit >>> from things like uncertainty and confidence in the future. >>> Certainly, >>> there is wisdom in drawing a line and saying "Ware Ye, Here Be >>> Dragons". >>> Even if you know that there are people living on the other side of >>> that >>> line happily, you can get on with your business, which is =20 >>> engineering >>> workable solutions. >>> >>> I suspect that this is primarily because people have trouble with =20 >>> the >>> vagaries inherent in mobile and wireless systems. For LoST, in >>> the here >>> and now, what you are asking for is a small change in the underlying >>> philosophy. This philosophy isn't necessarily written down, but >>> you will >>> find that this WG is currently operating under the assumption that >>> its >>> inputs will be simple. This gives solid, repeatable results; you =20 >>> can >>> write algorithms to that; and almost anyone can get it right. >>> Having one >>> result is nice - we don't want request forking, which is a >>> possibility >>> unless you have a clear one-to-one mapping from location to URI... >>> >>> location -> FG -> FG (-> FG ...) -> Tree -> URI >>> >>> You understand the vagaries, and are comfortable with them, but =20 >>> these >>> scare the willies out of most people - because you don't get >>> results in >>> nice tidy boxes. It's also harder to design a system that deals =20 >>> with >>> fuzzy inputs. To start with, you need a really compelling reason >>> to do >>> it. Then, you need to make it so easy to do that not doing it >>> would seem >>> recalcitrant. >>> >>> I personally like the idea of building in a little tolerance into =20 >>> the >>> whole system. And being able to convey this sort of information >>> could be >>> useful outside of an emergency situation as a sort of tuning >>> mechanism. >>> Certainly, it would be useful in combination with location >>> uncertainty and >>> confidence to know whether or not current location information is >>> adequate. >>> >>> But this is from the person that reminded GEOPRIV that location =20 >>> isn't >>> always a simple point in space. >>> >>> Cheers, >>> Martin >>> >>> ________________________________________ >>> From: Edge, Stephen [mailto:sedge@qualcomm.com] >>> Sent: Tuesday, 26 September 2006 2:36 PM >>> To: ecrit@ietf.org >>> Subject: [Ecrit] Indication of PSAP Confidence Level in a LoST Query >>> Response >>> >>> Hi All >>> Here is a topic that may or may not be new but maybe not yet >>> presented in >>> this light. In the not so distant future and certainly within the >>> possible >>> lifetime of the LoST capability, it may be possible using new >>> algorithms >>> and additional processing and storage availability to determine the >>> probability that a particular PSAP URI is the correct one for a >>> provided >>> geographic or civil location (taking account of the fact that any >>> provided >>> location will often include, implicitly or explicitly, some area of >>> uncertainty). This capability is possible in principle even today; >>> it is >>> just that the required amount of processing and storage may be too >>> high >>> (or the ability of currently known algorithms too low) to allow >>> realistic >>> and cost effective implementation. >>> >>> Assuming that a probability value, AKA confidence level, was >>> provided in a >>> LoST response, it would be possible with some solutions being >>> developed >>> (e.g. 3GPP and maybe 3GPP2) to obtain a more exact location for a >>> wireless >>> (or maybe wireline) user if the confidence value was not high and no >>> significant delay had yet been expended to obtain the initial >>> location. >>> That would then allow a second LoST query with a higher >>> probability of >>> success. It would also permit a network to instigate the initial =20 >>> LoST >>> query using simple location information such as cell ID requiring >>> no time >>> to obtain. The overall result could be significantly lower call =20 >>> delay >>> wherever an initial location mapped unambiguously to a single PSAP >>> URI and >>> more reliable routing for callers in PSAP border areas. >>> >>> This capability may seem strange in a wireline environment where a >>> terminal would typically stay put for extended periods of time >>> allowing >>> plenty of opportunity to obtain a location before an emergency >>> call was >>> originated. But in a wireless environment, it can be practically >>> impossible to know location with anything but very coarse accuracy >>> at any >>> arbitrary point in time and the time needed to obtain a location =20 >>> more >>> accurately can be significant. It should also be noted that such an >>> enhancement to LoST could be mostly independent of the means used to >>> obtain location (whether for the first or second query). In other >>> words, >>> such a capability need not (greatly) prejudice issues relating to =20 >>> the >>> architecture, procedures and methods used to obtain location. >>> >>> Of course, such an enhancement to LoST might be added later after >>> it was >>> well established that algorithms and computational capability >>> would be up >>> to the task. But the addition of an extra optional parameter to a >>> LoST >>> response need not impact implementations that choose not to use it >>> (either >>> as a client or server). And later implementation support would be >>> easier >>> because it would not require any new standards change. (Of course, >>> proprietary support would always be possible, but potentially >>> dangerous >>> because of the risk of LoST evolution in some other direction, >>> such as >>> provision of more than one PSAP URI.) >>> >>> One possible consequence of this proposal might be to encourage non- >>> uniformity in the algorithms used to convert location to PSAP URI - >>> meaning different implementations could occasionally deliver >>> different >>> URIs (and different confidence levels) for the same location input >>> and >>> same PSAP database map. But I wonder if this should really be an >>> issue - >>> e.g. it may well turn out that some algorithms are better (more >>> reliable, >>> faster etc.) than others and that a demonstration of this in a live >>> environment would be a good way to ensure that the better ones >>> eventually >>> become the ones most widely adopted. >>> >>> Anyhow, please comment on this. >>> Kind Regards >>> Stephen >>> -------------------------------------------------------------------- >>> - > >>> ----- >>> ---------------------- >>> This message is for the designated recipient only and may >>> contain privileged, proprietary, or otherwise private information. >>> If you have received it in error, please notify the sender >>> immediately and delete the original. Any unauthorized use of >>> this email is prohibited. >>> -------------------------------------------------------------------- >>> - > >>> ----- >>> ---------------------- >>> [mf2] >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 27 03:37:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSTym-0008LC-FV; Wed, 27 Sep 2006 03:37:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSTyl-0008L7-Eh for ecrit@ietf.org; Wed, 27 Sep 2006 03:37:15 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GSTyk-0001QF-R9 for ecrit@ietf.org; Wed, 27 Sep 2006 03:37:15 -0400 Received: (qmail invoked by alias); 27 Sep 2006 07:37:13 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp042) with SMTP; 27 Sep 2006 09:37:13 +0200 X-Authenticated: #29516787 Message-ID: <451A2A27.4030206@gmx.net> Date: Wed, 27 Sep 2006 09:37:11 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Leslie Daigle References: <000001c6db7c$03db01f0$1152150a@amer.cisco.com> <45102B8C.5080803@gmx.net> <45102D53.5020205@gmx.net> <45114C31.1060901@hxr.us> <4511C03D.9040100@thinkingcat.com> <4513974A.1000504@gmx.net> <4519B40F.8030103@thinkingcat.com> In-Reply-To: <4519B40F.8030103@thinkingcat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.6 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: "Ecrit@Ietf.Org" Subject: [Ecrit] Draft Update: draft-polk-ecrit-dhc-lost-discovery-01.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Leslie, how naive from my side to think that RFC 3361 and RFC 3319 went through the IETF process without complications. Anyway, I have addressed the comments and submitted a draft update: http://www.tschofenig.priv.at/svn/draft-tschofenig-dhc-lost-discovery/draft-polk-ecrit-dhc-lost-discovery-01.txt Ciao Hannes PS: Currently, the draft does not allow more than one domain name. If useful then I am going to change it. Leslie Daigle schrieb: > > Hi Hannes, > > Hannes Tschofenig wrote: > > > > I am just curious why the mechanisms used for SIP are not good enough > > for our purpose. > > If you're referring to RFC3263 -- observe that 3263<3401 (the > final publication number of the DDDS spec) :-) > > I.e., the SIP location service was defined when NAPTR-based > application specification was caught in IESG-limbo-hell (yes, I remember > when "final" documents disappeared into the IESG for 6 months > at a stretch, and your AD didn't reply to your e-mail, EVER, and > there WAS NO I-D TRACKER! *ahem* sorry... just had to get that > twitch over with ;-) ). > > So -- if the SIP location service was defined today, it would have > different text. > >> I just to make sure that I understand you right. With the third option >> you would use the DHCP option to return an FQDN (instead of a domain >> name) and use it as input to the U-NAPTR-based discovery found in the >> LoST specification. > > Yes -- with the adjustment to the above that you & Andy later agreed > on ("instead of an IP address"). > > That would align with the material in draft-ietf-ecrit-lost-01.txt -- > i.e., that domain names are used in a U-NAPTR application to produce > the actual URI(s) of the LoST server(s). > > I'd suggest this text: > > The option MAY contain multiple domain names, but these SHOULD refer > to different NAPTR records, rather than different A records. The > client MUST try the records in the order listed. The client only > resolves the subsequent domain names if attempts to contact the first > one failed or yielded no common transport protocols between client > and server or denote a domain administratively prohibited by client > policy. > > Use of multiple domain names is not meant to replace NAPTR (?TBD?) > and SRV records, but rather to allow a single DHCP server to indicate > LoST servers operated by multiple providers. > > > wants to become something like this: > > > The option MAY contain multiple domain names, each of which can > separately be used to locate an appropriate LoST service as > outlined in (). The client only > resolves the subsequent domain names if attempts to contact the first > one failed or yielded no common transport protocols between client > and server or denote a domain administratively prohibited by client > policy. > > > And then this: > > Use of multiple domain names is not meant to replace NAPTR (?TBD?) > and SRV records, but rather to allow a single DHCP server to indicate > LoST servers operated by multiple providers. > > should actually be handled in the draft-ietf-ecrit-lost-01.txt document > (IMO) -- an illustration of how you can use one FQDN and point > to several different services operated by various providers. > > To borrow a text illustration from the S-NAPTR document, you already > get at least 2 opportunities to "share the load" in ?-NAPTR: > > > > Thus, to find the EM services for thinkingcat.example, the NAPTR > records for thinkingcat.example are retrieved: > > thinkingcat.example. > ;; order pref flags > IN NAPTR 100 10 "s" "EM:ProtA" ( ; service > "" ; regexp > _ProtA._tcp.thinkingcat.example. ; replacement > ) > IN NAPTR 100 20 "s" "EM:ProtB" ( ; service > "" ; regexp > _ProtB._tcp.example.com. ; replacement > ) > IN NAPTR 100 30 "s" "EM:ProtC" ( ; service > "" ; regexp > _ProtC._tcp.example.com. ; replacement > ) > > Then the administrators at example.com can manage the preference > rankings of the servers they use to support the ProtB service: > > _ProtB._tcp.example.com. > ;; Pref Weight Port Target > IN SRV 10 0 10001 bigiron.example.com. > IN SRV 20 0 10001 backup.em.example.com. > IN SRV 30 0 10001 nuclearfallout.australia-isp.example. > > > > > > Leslie. > >> >> Ciao >> Hannes >> >> Leslie Daigle schrieb: >>> >>> Further -- as noted in all the DDDS documentation, NAPTR >>> records don't exist "in the wild"; they are always part of a >>> DDDS application (in this case, U-NAPTR). >>> >>> So -- it seems that the 3rd option should really be about >>> specifying the application unique string that feeds into >>> the U-NAPTR-based LoST discovery specification. The >>> application unique string would, in fact, be an FQDN. >>> >>> If you really need another layer of indirection (and I suspect >>> Andy is right, you don't), you could still have multiple >>> AUS's. >>> >>> Leslie. >>> >>> Andrew Newton wrote: >>>> Hannes Tschofenig wrote: >>>>> We used the procedure used in RFC 3361 and from RFC 3319. >>>>> >>>>> RFC 3361 >>>>> Dynamic Host Configuration Protocol (DHCP-for-IPv4) >>>>> Option for Session Initiation Protocol (SIP) Servers >>>>> >>>>> RFC 3319 >>>>> >>>>> Dynamic Host Configuration Protocol (DHCPv6) Options >>>>> for Session Initiation Protocol (SIP) Servers >>>> >>>> Yes, it looks very similar. But the usages for SIP and LoST are >>>> very different. The problem is that your LoST location configuration >>>> with DHCP is actually non-interoperable with the current LoST >>>> specification. >>>> >>>> dhc-lost-discovery describes three methods of configuration: >>>> >>>> 1) IP address(es). >>>> 2) A record lookup. >>>> 3) Multiple NAPTR record lookups. >>>> >>>> The problem with the 1 and 2 is that they don't do enough. The >>>> U-NAPTR resolution specified in LoST could, and likely should, >>>> result in HTTP URIs that use ports other than 80 with specific query >>>> paths. As an example: https://example.com:4433/lost/. Neither an >>>> IP address nor an A record is enough information to construct that URI. >>>> >>>> The problem with option 3 is that it fails to understand how DNS and >>>> U-NAPTR work. Your specification says that when multiple DNS qnames >>>> are present, they are used to query multiple NAPTR records. Why? >>>> The query against one qname can result in multiple NAPTR records. >>>> What's the purpose of adding a layer above the U-NAPTR algorithm? >>>> >>>> I can only conclude that this draft is incompatible with the work >>>> already accepted by ECRIT, and therefore should not be accepted as a >>>> working group item until it is fixed. >>>> >>>> To be quite clear, I like the idea of using DHCP to configure a >>>> pointer to the LoST server, and I'd be in favor of working group >>>> acceptance of a document that did it in a way compatible with LoST. >>>> >>>> -andy >>>> >>> >>> >> > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 27 07:42:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSXnu-0005hX-8M; Wed, 27 Sep 2006 07:42:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSXns-0005hS-Lh for ecrit@ietf.org; Wed, 27 Sep 2006 07:42:16 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSXnr-0004hU-P6 for ecrit@ietf.org; Wed, 27 Sep 2006 07:42:16 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GSXnj-0003bx-M0; Wed, 27 Sep 2006 06:42:09 -0500 From: "Brian Rosen" To: "'Edge, Stephen'" , "'Henning Schulzrinne'" Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a LoST QueryResponse Date: Wed, 27 Sep 2006 07:42:07 -0400 Message-ID: <0b8c01c6e229$f88f1160$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acbh16UKFMGg2o6IR+iaxBlT2KdcAwACn8oQABGgsCA= In-Reply-To: <21A52261514BE844AB662C1C21A29EA928967A@NAEX13.na.qualcomm.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 398dc098b38497efe55f044562a219e7 Cc: 'ECRIT' , "'Thomson, Martin'" 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: , Errors-To: ecrit-bounces@ietf.org A while ago, we had a discussion of whether there was a need to express = cell site and sector as an input format to LoST. I took an action to ask = NENA. The "official" answer is not yet available, but unofficially, I can = state that there was no support for this idea anywhere. =20 In fact, there was no support for representing cell site and sector by anything except a point, which might be a civic or a geo. The reality = is that the PSAPs and the wireless carriers get together and DECIDE which = PSAP gets calls from each cell site/sector. Although there are frequent = changes in the tower arrangements, it seems there is a choice made who gets the call. Picking a point that lies within the desired PSAP boundary seems = to be a very acceptable mechanism. Now, I think this is somewhat na=EFve, based on current experience, and = may need to be revisited as technology evolves. However, we asked the = question of the experts, and that=92s what they said they wanted. In this case, = we had significant wireless carrier and PSAP participation in the discussion. Although "quick fix" technology is getting better, and more prevalent, = and proliferation of location based services means more of the mechanism is "turned on" all the time, most calls emergency calls are still routed by cell site/sector. More accurate information is obtained much later in = the call (15 seconds is a typical number). Representing this location as a point is the current answer, and I think that's all we should do now, = even though I personally think we will need more. Brian > -----Original Message----- > From: Edge, Stephen [mailto:sedge@qualcomm.com] > Sent: Wednesday, September 27, 2006 12:38 AM > To: Henning Schulzrinne > Cc: Brian Rosen; Thomson, Martin; ECRIT > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a LoST > QueryResponse >=20 > Hi Henning >=20 > Thanks for the further comments. I appreciate the points you are = making. >=20 > For many wireless networks (e.g. 3GPP UMTS, cdma2000), a cell-sector = ID > is all the network may generally receive from a terminal inside a SIP > INVITE - since any more accurate location may cost too much in time > (e.g. might not be associated by the network with an emergency call = and > hence not assigned priority status). With the 3GPP current = architecture > (3GPP2 has not yet decided one), this will be passed to an E-CSCF in = the > serving network and thence to an LRF (Location Retrieval Function) for > use in deriving the PSAP URI. The LRF may be able to instigate more > accurate location (e.g. using a user plane location solution like SUPL > or using the 3GPP control plane solution) but this will take time and > resources. If it turns out that the cell-sector ID maps to a PSAP URI > with high confidence in a majority of cases, there would seem to be = some > benefit in performing this mapping rather than adding extra delay by > attempting to obtain a more accurate location. Note that this is now = an > issue of call delay just as much as routing reliability which may be > significant so long as legacy PSAPs have to be supported and there is > delay on both the packet and circuit mode sides as well as in = providing > the interworking. >=20 > I should also point out that the proposed capability is generally not > possible for circuit mode wireless calls because the control points = for > location and routing are separate. Using the same control point for = both > functions allows an improvement (in terms of resource efficiency, call > delay and routing reliability) over circuit mode that could provide a > better service. >=20 > I agree that removing unnecessary complexity from the service and = server > is worthwhile but I am not sure that an optional capability that can = be > omitted initially should count very heavily. For example, it is = possible > that algorithms that reliably deliver the most probable PSAP = destination > (I mean the truly most probable one and not an approximation based on > centroids or other approximate data) will need the capability to = compute > some confidence measure anyway as part of the selection process. >=20 > I suppose one conclusion of this discussion (given the direction in > which it seems headed) would be to leave out this capability initially > and then, based on actual call delay and routing results, reconsider = it > or something similar later if needed. >=20 > Kind Regards >=20 > Stephen > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, September 26, 2006 6:52 PM > To: Edge, Stephen > Cc: Brian Rosen; Thomson, Martin; ECRIT > Subject: Re: [Ecrit] Indication of PSAP Confidence Level in a LoST > QueryResponse >=20 > Stephen, >=20 > any engineering is a trade-off between functionality and complexity. > Speaking from some experience, I so far have always regretted when > erring on the side of complexity, on the "it could be useful" theory. > I have no intention of repeating this mistake for LoST, particularly > for a truly mission-critical system. >=20 > You probably would want to review the list discussion as to why I > believe any marginal increase in "correct" routing is just not worth > the tremendous cost in overall system complexity and > unpredictability. I won't bore the rest of the list by repeating = these. >=20 > I just don't see cell sector as useful, long term, so whether it > could actually work in some large number of cases is rather > immaterial. Since we know that it will fail, regardless of > probability routing or not, in an unacceptably large number of cases, > it seems much better to design a system that actually works, > particularly given that the technology is available and now standard > on most modern cell phones. Old cell phone systems won't be running > LoST anyway. >=20 > I have to admit that I find it rather uninteresting whether I call > the wrong PSAP if I'm 100 ft from the border of the PSAP. You'll > always have cases where the initial route goes to PSAP A, but the > caller moves to PSAP B while talking to the call taker. In the town I > live, it probably takes about 2 minutes, at 30 mph, to cross the PSAP > coverage area. Within that range, I'm also just as likely to report > on an incident on the other side of the town border. Again, lots of > complexity for no operational gain. >=20 > While it is theoretically possible, with some very low probability, > to end up exactly on the border between two PSAPs, in that case, it > just doesn't matter what happens and whether two implementations do > the same thing. By definition, either PSAP is as good the other. >=20 > In those rare cases where the client cares, it can do the > probabilistic computation. I'd rather have those that care, pay the > cost, rather than everyone. >=20 > Henning >=20 > On Sep 26, 2006, at 9:28 PM, Edge, Stephen wrote: >=20 > > Hi All > > > > Thanks for the comments (Martin, Brian, Henning). Though not too > > encouraging so far, here are a few responses. > > > > Martin's comments: I am not proposing including = confidence/probability > > information in the LoST query (just a geographic shape would do) > > although I believe it would help. My proposal is just to allow > > optional > > addition of a confidence value associated with a single PSAP URI > > result > > in the LoST response. That way the call server knows the likelihood = of > > misrouting (e.g. in some cases could be 50% or higher). If it turns > > out > > that the chosen PSAP is not even E911 phase 2 capable, there could > > be a > > major problem in rerouting to the correct PSAP because the initially > > chosen PSAP will not be able to receive a more accurate location > > estimate. However, I agree that this proposed capability may not be > > very > > useful initially because servers may not support it and clients may > > not > > be adaptable enough to take advantage. However, that could change in = a > > few years as algorithms get smarter. For example, it would probably = be > > quite simple to perform some of the calculations in non-real time - > > e.g. > > associate each cell ID with a single PSAP URI and confidence level > > - and > > perform a simple lookup in real time. If the capability is not > > allowed, > > then it won't be possible (or at least not so straightforward) to > > improve call setup time and routing reliability - which would be a > > pity. > > > > Brian's comments: I agree that one input could be a hard edged = polygon > > in which case (if a uniform probability distribution is assumed), = the > > resulting confidence is just the proportional overlap with the PSAP > > coverage area. For some positioning methods (e.g. yielding other > > shapes), a probability distribution can be assumed in which case the > > calculation of the confidence would be more complex (but still > > possible). The LoST response can remain deterministic (assuming > > "perfect > > algorithms") as long as the allowed geographic shape inputs are > > defined > > carefully enough (e.g. state any default confidence level and/or > > probability distribution). This is not to say that different > > algorithms > > (or possibly even different implementations of the same algorithm) > > would > > always yield the same results - in fact, due to approximations, > > programming errors and shortcuts etc. they probably would not no > > matter > > how simple you make the protocol definition (e.g. consider a point > > input > > exactly on a PSAP boundary). > > > > Henning's comments: you seem to be saying that cell-sector based > > location estimates will typically cause routing errors whereas with > > more > > accurate (E911 phase 2 type) location, any routing error = (considering > > that the terminal will be very close to the destination PSAP's > > coverage > > area) will not be important. I have a somewhat different view though > > based on similar premises. For a given geographic area location > > input L, > > consider 2 possible results: (a) L is within one PSAP's coverage = area > > with a confidence level >=3DX (e.g. X =3D 90%); (b) L spans >=3D2 = PSAP areas > > with a confidence level > significant > > frequency when L is cell-sector based (which I would find hard to > > doubt > > given the large numbers of small urban cells and some large PSAP > > coverage areas), then using cell-sector as an initial input could be > > sensible. For (b), there may be value in obtaining more accurate > > location information because the smaller the size of L, the higher > > will > > be the incidence of (a). (b) will still occur sometimes no matter = how > > small L becomes (unless a point), but then the argument that any > > resulting routing error is less important comes to the rescue and = you > > end up with a methodology that can both reduce call delay and = improve > > routing reliability. (Note concerning Monte Carlo sampling by the > > client: I agree that is one solution but rather inefficient, also > > complex for the client.) > > > > I look forward to more comments which hopefully can progress this. > > > > Kind Regards > > > > Stephen > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Tuesday, September 26, 2006 5:26 AM > > To: Brian Rosen > > Cc: Edge, Stephen; ECRIT > > Subject: Re: [Ecrit] Indication of PSAP Confidence Level in a LoST > > QueryResponse > > > > I'll also add that earlier discussion has yielded the insight that > > sector-size areas are pretty useless for call routing, as there is a > > significant probability of mis-routes. > > > > This probability won't be reduced all that much by fancy area > > maximization techniques or anything else since you simply can't tell > > which of the PSAP serving areas you're in. With area maximization, > > for example, users in a cell sector will simply be assigned to > > whatever PSAP service area dominates the cell sector. On average, > > across cell towers, that will still make it a 50/50 toss-up. > > > > For dispatch, mid-sized areas of uncertainty are useful, > > corresponding to the typical FCC-compliant uncertainty regions of a > > few hundred feet. However, worrying that such areas span multiple > > PSAPs and then trying to pick the right one seems rather pointless > > (sorry...), given the complexity. (If clients really care, they can > > randomly sample the area, essentially doing a Monte-Carlo = simulation, > > which will yield an area maximization by design.) > > > > Thus, I just don't see the benefit. Either the area of uncertainty = is > > too large for routing, as it is for tower/face information, or it is > > too small to worry about the right PSAP, and can be treated as a > > point for PSAP selection purposes. > > > > > > Henning > > > > On Sep 26, 2006, at 7:28 AM, Brian Rosen wrote: > > > >> I'm not sure I understand what you are proposing. The service > >> boundaries > >> are hard edged polygons. If you put a point in, you get an exact > >> answer > >> out. If you put a shape in, then we could have some kind of > >> overlap of the > >> boundary polygons with the shape, and get uncertainty from that. > >> Is that > >> what you were proposing? > >> > >> If so, I think I would support some kind of output that told you > >> how close > >> of a fit we got. If that's not it, perhaps you would explain in > >> more detail > >> what you propose. > >> > >> I do think we are pushing for the LoST resolver to be simple and > >> deterministic. The reason is that it is not in a position to > >> understand > >> what the tradeoffs are. In general, the closer you get to the > >> origin of the > >> location information, the more you understand what is actually > >> happening on > >> the ground. We want earlier elements to make the decisions, and > >> not later > >> elements. Thus we insist that if you have more than one location, > >> the > >> client chooses, and not the server. If we force the client to > >> interpret > >> inexactness, then I think giving it as much information to make the > >> choice > >> as we can is a useful thing to do. > >> > >> Brian > >> > >>> -----Original Message----- > >>> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > >>> Sent: Tuesday, September 26, 2006 2:58 AM > >>> To: Edge, Stephen; ecrit@ietf.org > >>> Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a LoST > >>> QueryResponse > >>> > >>> Hi Stephen, > >>> > >>> I must admit, that I can't see any tangible benefits for this > >>> right now - > >>> that is probably going to be the biggest point leveled against = this > >>> proposal. > >>> > >>> These sorts of discussion have been run in the past. Consider the > >>> discussions on whether or not uncertainty should be included in = LoST > >>> (check the archives; it was in the last few weeks). And GEOPRIV > >>> have > >>> discussed confidence on the past, and aside from problems with > >>> people > >>> understanding the concepts, the main point against its inclusion > >>> was the > >>> lack of perceived benefit. > >>> > >>> You are probably correct, in that we don't know today how we could > >>> benefit > >>> from things like uncertainty and confidence in the future. > >>> Certainly, > >>> there is wisdom in drawing a line and saying "Ware Ye, Here Be > >>> Dragons". > >>> Even if you know that there are people living on the other side of > >>> that > >>> line happily, you can get on with your business, which is > >>> engineering > >>> workable solutions. > >>> > >>> I suspect that this is primarily because people have trouble with > >>> the > >>> vagaries inherent in mobile and wireless systems. For LoST, in > >>> the here > >>> and now, what you are asking for is a small change in the = underlying > >>> philosophy. This philosophy isn't necessarily written down, but > >>> you will > >>> find that this WG is currently operating under the assumption that > >>> its > >>> inputs will be simple. This gives solid, repeatable results; you > >>> can > >>> write algorithms to that; and almost anyone can get it right. > >>> Having one > >>> result is nice - we don't want request forking, which is a > >>> possibility > >>> unless you have a clear one-to-one mapping from location to URI... > >>> > >>> location -> FG -> FG (-> FG ...) -> Tree -> URI > >>> > >>> You understand the vagaries, and are comfortable with them, but > >>> these > >>> scare the willies out of most people - because you don't get > >>> results in > >>> nice tidy boxes. It's also harder to design a system that deals > >>> with > >>> fuzzy inputs. To start with, you need a really compelling reason > >>> to do > >>> it. Then, you need to make it so easy to do that not doing it > >>> would seem > >>> recalcitrant. > >>> > >>> I personally like the idea of building in a little tolerance into > >>> the > >>> whole system. And being able to convey this sort of information > >>> could be > >>> useful outside of an emergency situation as a sort of tuning > >>> mechanism. > >>> Certainly, it would be useful in combination with location > >>> uncertainty and > >>> confidence to know whether or not current location information is > >>> adequate. > >>> > >>> But this is from the person that reminded GEOPRIV that location > >>> isn't > >>> always a simple point in space. > >>> > >>> Cheers, > >>> Martin > >>> > >>> ________________________________________ > >>> From: Edge, Stephen [mailto:sedge@qualcomm.com] > >>> Sent: Tuesday, 26 September 2006 2:36 PM > >>> To: ecrit@ietf.org > >>> Subject: [Ecrit] Indication of PSAP Confidence Level in a LoST = Query > >>> Response > >>> > >>> Hi All > >>> Here is a topic that may or may not be new but maybe not yet > >>> presented in > >>> this light. In the not so distant future and certainly within the > >>> possible > >>> lifetime of the LoST capability, it may be possible using new > >>> algorithms > >>> and additional processing and storage availability to determine = the > >>> probability that a particular PSAP URI is the correct one for a > >>> provided > >>> geographic or civil location (taking account of the fact that any > >>> provided > >>> location will often include, implicitly or explicitly, some area = of > >>> uncertainty). This capability is possible in principle even today; > >>> it is > >>> just that the required amount of processing and storage may be too > >>> high > >>> (or the ability of currently known algorithms too low) to allow > >>> realistic > >>> and cost effective implementation. > >>> > >>> Assuming that a probability value, AKA confidence level, was > >>> provided in a > >>> LoST response, it would be possible with some solutions being > >>> developed > >>> (e.g. 3GPP and maybe 3GPP2) to obtain a more exact location for a > >>> wireless > >>> (or maybe wireline) user if the confidence value was not high and = no > >>> significant delay had yet been expended to obtain the initial > >>> location. > >>> That would then allow a second LoST query with a higher > >>> probability of > >>> success. It would also permit a network to instigate the initial > >>> LoST > >>> query using simple location information such as cell ID requiring > >>> no time > >>> to obtain. The overall result could be significantly lower call > >>> delay > >>> wherever an initial location mapped unambiguously to a single PSAP > >>> URI and > >>> more reliable routing for callers in PSAP border areas. > >>> > >>> This capability may seem strange in a wireline environment where a > >>> terminal would typically stay put for extended periods of time > >>> allowing > >>> plenty of opportunity to obtain a location before an emergency > >>> call was > >>> originated. But in a wireless environment, it can be practically > >>> impossible to know location with anything but very coarse accuracy > >>> at any > >>> arbitrary point in time and the time needed to obtain a location > >>> more > >>> accurately can be significant. It should also be noted that such = an > >>> enhancement to LoST could be mostly independent of the means used = to > >>> obtain location (whether for the first or second query). In other > >>> words, > >>> such a capability need not (greatly) prejudice issues relating to > >>> the > >>> architecture, procedures and methods used to obtain location. > >>> > >>> Of course, such an enhancement to LoST might be added later after > >>> it was > >>> well established that algorithms and computational capability > >>> would be up > >>> to the task. But the addition of an extra optional parameter to a > >>> LoST > >>> response need not impact implementations that choose not to use it > >>> (either > >>> as a client or server). And later implementation support would be > >>> easier > >>> because it would not require any new standards change. (Of course, > >>> proprietary support would always be possible, but potentially > >>> dangerous > >>> because of the risk of LoST evolution in some other direction, > >>> such as > >>> provision of more than one PSAP URI.) > >>> > >>> One possible consequence of this proposal might be to encourage = non- > >>> uniformity in the algorithms used to convert location to PSAP URI = - > >>> meaning different implementations could occasionally deliver > >>> different > >>> URIs (and different confidence levels) for the same location input > >>> and > >>> same PSAP database map. But I wonder if this should really be an > >>> issue - > >>> e.g. it may well turn out that some algorithms are better (more > >>> reliable, > >>> faster etc.) than others and that a demonstration of this in a = live > >>> environment would be a good way to ensure that the better ones > >>> eventually > >>> become the ones most widely adopted. > >>> > >>> Anyhow, please comment on this. > >>> Kind Regards > >>> Stephen > >>> = -------------------------------------------------------------------- >=20 > >>> - > > > >>> ----- > >>> ---------------------- > >>> This message is for the designated recipient only and may > >>> contain privileged, proprietary, or otherwise private information. > >>> If you have received it in error, please notify the sender > >>> immediately and delete the original. Any unauthorized use of > >>> this email is prohibited. > >>> = -------------------------------------------------------------------- >=20 > >>> - > > > >>> ----- > >>> ---------------------- > >>> [mf2] > >> > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 27 09:07:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSZ8L-0000IV-46; Wed, 27 Sep 2006 09:07:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSZ8J-0000H3-BV for ecrit@ietf.org; Wed, 27 Sep 2006 09:07:27 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSZ8H-0004zj-4Z for ecrit@ietf.org; Wed, 27 Sep 2006 09:07:27 -0400 Received: from [192.168.0.41] (pool-141-153-175-20.mad.east.verizon.net [141.153.175.20]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k8RD7Mu9012092 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 27 Sep 2006 09:07:23 -0400 (EDT) In-Reply-To: <21A52261514BE844AB662C1C21A29EA928967A@NAEX13.na.qualcomm.com> References: <21A52261514BE844AB662C1C21A29EA928967A@NAEX13.na.qualcomm.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <40663334-CCAA-4234-AFAC-FB4C79F90AD9@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Indication of PSAP Confidence Level in a LoST QueryResponse Date: Wed, 27 Sep 2006 09:07:14 -0400 To: "Edge, Stephen" X-Mailer: Apple Mail (2.752.2) X-PerlMx-Spam: Gauge=XXII, Probability=22%, X-Seen-By filter2.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > > I suppose one conclusion of this discussion (given the direction in > which it seems headed) would be to leave out this capability initially > and then, based on actual call delay and routing results, > reconsider it > or something similar later if needed. I agree with that general conclusion; nothing in the design of LoST prevents such an addition at a later time. As with any distributed system with many components operated by different jurisdictions, upgrading all components at the same time may well be difficult. One possible solution, which is roughly in the spec right now but needs some additional work, is to specify only a 3D-point as mandatory and allow the inclusion of another "fancy" (some 3D) location object that servers are free to ignore. That way, "old" or "simple" systems will do roughly the right thing, without preventing advanced implementations. You don't want to get the situation that the first resolver doesn't understand the new location object, and thus can't pass the request to others (or, maybe worse, that some LoST server in the middle of a referral chain chokes on the format). Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 27 12:15:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSc3q-0003dF-JF; Wed, 27 Sep 2006 12:15:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSc3o-0003d7-Tc for ecrit@ietf.org; Wed, 27 Sep 2006 12:15:00 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSc3l-00089R-VC for ecrit@ietf.org; Wed, 27 Sep 2006 12:15:00 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.6/IER-o) with ESMTP id k8RGDwjG001895; Wed, 27 Sep 2006 11:13:58 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 27 Sep 2006 11:13:58 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 27 Sep 2006 18:13:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a LoSTQueryResponse Date: Wed, 27 Sep 2006 18:13:56 +0200 Message-ID: <5D1A7985295922448D5550C94DE291804E31CC@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Indication of PSAP Confidence Level in a LoSTQueryResponse Thread-Index: Acbh16UKFMGg2o6IR+iaxBlT2KdcAwACn8oQABGgsCAAA4iNEA== From: "Drage, Keith \(Keith\)" To: "Brian Rosen" , "Edge, Stephen" , "Henning Schulzrinne" X-OriginalArrivalTime: 27 Sep 2006 16:13:56.0719 (UTC) FILETIME=[EF07AFF0:01C6E24F] X-Spam-Score: 0.0 (/) X-Scan-Signature: c96e11e58076fc8e92061fb6cbdfae15 Cc: ECRIT , "Thomson, Martin" 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: , Errors-To: ecrit-bounces@ietf.org Some of the terms like "anywhere" are very general. I am unclear whether = you are giving a response based on NENA knowledge or a wider knowledge. Remember the scope of ECRIT is to cover worldwide requirements, not just = NAR. Can you rephrase you answer in terms of the geographical areas = where you believe this is the answer, thus therefore identifying those = regions where you do not have knowledge of the answer. Regards Keith=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: 27 September 2006 12:42 > To: 'Edge, Stephen'; 'Henning Schulzrinne' > Cc: 'ECRIT'; 'Thomson, Martin' > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a=20 > LoSTQueryResponse >=20 > A while ago, we had a discussion of whether there was a need=20 > to express cell site and sector as an input format to LoST. =20 > I took an action to ask NENA. > The "official" answer is not yet available, but unofficially,=20 > I can state that there was no support for this idea anywhere. =20 >=20 > In fact, there was no support for representing cell site and=20 > sector by anything except a point, which might be a civic or=20 > a geo. The reality is that the PSAPs and the wireless=20 > carriers get together and DECIDE which PSAP gets calls from=20 > each cell site/sector. Although there are frequent changes=20 > in the tower arrangements, it seems there is a choice made=20 > who gets the call. Picking a point that lies within the=20 > desired PSAP boundary seems to be a very acceptable mechanism. >=20 > Now, I think this is somewhat na=EFve, based on current=20 > experience, and may need to be revisited as technology=20 > evolves. However, we asked the question of the experts, and=20 > that's what they said they wanted. In this case, we had=20 > significant wireless carrier and PSAP participation in the discussion. >=20 > Although "quick fix" technology is getting better, and more=20 > prevalent, and proliferation of location based services means=20 > more of the mechanism is "turned on" all the time, most calls=20 > emergency calls are still routed by cell site/sector. More=20 > accurate information is obtained much later in the call (15=20 > seconds is a typical number). Representing this location as=20 > a point is the current answer, and I think that's all we=20 > should do now, even though I personally think we will need more. >=20 > Brian >=20 > > -----Original Message----- > > From: Edge, Stephen [mailto:sedge@qualcomm.com] > > Sent: Wednesday, September 27, 2006 12:38 AM > > To: Henning Schulzrinne > > Cc: Brian Rosen; Thomson, Martin; ECRIT > > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a LoST=20 > > QueryResponse > >=20 > > Hi Henning > >=20 > > Thanks for the further comments. I appreciate the points=20 > you are making. > >=20 > > For many wireless networks (e.g. 3GPP UMTS, cdma2000), a=20 > cell-sector=20 > > ID is all the network may generally receive from a terminal=20 > inside a=20 > > SIP INVITE - since any more accurate location may cost too much in=20 > > time (e.g. might not be associated by the network with an emergency=20 > > call and hence not assigned priority status). With the 3GPP current=20 > > architecture > > (3GPP2 has not yet decided one), this will be passed to an=20 > E-CSCF in=20 > > the serving network and thence to an LRF (Location=20 > Retrieval Function)=20 > > for use in deriving the PSAP URI. The LRF may be able to instigate=20 > > more accurate location (e.g. using a user plane location=20 > solution like=20 > > SUPL or using the 3GPP control plane solution) but this=20 > will take time=20 > > and resources. If it turns out that the cell-sector ID maps=20 > to a PSAP=20 > > URI with high confidence in a majority of cases, there=20 > would seem to=20 > > be some benefit in performing this mapping rather than adding extra=20 > > delay by attempting to obtain a more accurate location.=20 > Note that this=20 > > is now an issue of call delay just as much as routing reliability=20 > > which may be significant so long as legacy PSAPs have to be=20 > supported=20 > > and there is delay on both the packet and circuit mode=20 > sides as well=20 > > as in providing the interworking. > >=20 > > I should also point out that the proposed capability is=20 > generally not=20 > > possible for circuit mode wireless calls because the control points=20 > > for location and routing are separate. Using the same control point=20 > > for both functions allows an improvement (in terms of resource=20 > > efficiency, call delay and routing reliability) over=20 > circuit mode that=20 > > could provide a better service. > >=20 > > I agree that removing unnecessary complexity from the service and=20 > > server is worthwhile but I am not sure that an optional capability=20 > > that can be omitted initially should count very heavily.=20 > For example,=20 > > it is possible that algorithms that reliably deliver the=20 > most probable=20 > > PSAP destination (I mean the truly most probable one and not an=20 > > approximation based on centroids or other approximate data)=20 > will need=20 > > the capability to compute some confidence measure anyway as=20 > part of the selection process. > >=20 > > I suppose one conclusion of this discussion (given the direction in=20 > > which it seems headed) would be to leave out this=20 > capability initially=20 > > and then, based on actual call delay and routing results,=20 > reconsider=20 > > it or something similar later if needed. > >=20 > > Kind Regards > >=20 > > Stephen > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Tuesday, September 26, 2006 6:52 PM > > To: Edge, Stephen > > Cc: Brian Rosen; Thomson, Martin; ECRIT > > Subject: Re: [Ecrit] Indication of PSAP Confidence Level in a LoST=20 > > QueryResponse > >=20 > > Stephen, > >=20 > > any engineering is a trade-off between functionality and complexity. > > Speaking from some experience, I so far have always regretted when=20 > > erring on the side of complexity, on the "it could be=20 > useful" theory. > > I have no intention of repeating this mistake for LoST,=20 > particularly=20 > > for a truly mission-critical system. > >=20 > > You probably would want to review the list discussion as to why I=20 > > believe any marginal increase in "correct" routing is just=20 > not worth=20 > > the tremendous cost in overall system complexity and=20 > unpredictability.=20 > > I won't bore the rest of the list by repeating these. > >=20 > > I just don't see cell sector as useful, long term, so=20 > whether it could=20 > > actually work in some large number of cases is rather immaterial.=20 > > Since we know that it will fail, regardless of probability=20 > routing or=20 > > not, in an unacceptably large number of cases, it seems=20 > much better to=20 > > design a system that actually works, particularly given that the=20 > > technology is available and now standard on most modern=20 > cell phones.=20 > > Old cell phone systems won't be running LoST anyway. > >=20 > > I have to admit that I find it rather uninteresting whether=20 > I call the=20 > > wrong PSAP if I'm 100 ft from the border of the PSAP. =20 > You'll always=20 > > have cases where the initial route goes to PSAP A, but the caller=20 > > moves to PSAP B while talking to the call taker. In the=20 > town I live,=20 > > it probably takes about 2 minutes, at 30 mph, to cross the PSAP=20 > > coverage area. Within that range, I'm also just as likely=20 > to report on=20 > > an incident on the other side of the town border. Again, lots of=20 > > complexity for no operational gain. > >=20 > > While it is theoretically possible, with some very low=20 > probability, to=20 > > end up exactly on the border between two PSAPs, in that=20 > case, it just=20 > > doesn't matter what happens and whether two implementations do the=20 > > same thing. By definition, either PSAP is as good the other. > >=20 > > In those rare cases where the client cares, it can do the=20 > > probabilistic computation. I'd rather have those that care, pay the=20 > > cost, rather than everyone. > >=20 > > Henning > >=20 > > On Sep 26, 2006, at 9:28 PM, Edge, Stephen wrote: > >=20 > > > Hi All > > > > > > Thanks for the comments (Martin, Brian, Henning). Though not too=20 > > > encouraging so far, here are a few responses. > > > > > > Martin's comments: I am not proposing including=20 > > > confidence/probability information in the LoST query (just a=20 > > > geographic shape would do) although I believe it would help. My=20 > > > proposal is just to allow optional addition of a confidence value=20 > > > associated with a single PSAP URI result in the LoST=20 > response. That=20 > > > way the call server knows the likelihood of misrouting=20 > (e.g. in some=20 > > > cases could be 50% or higher). If it turns out that the=20 > chosen PSAP=20 > > > is not even E911 phase 2 capable, there could be a major=20 > problem in=20 > > > rerouting to the correct PSAP because the initially=20 > chosen PSAP will=20 > > > not be able to receive a more accurate location estimate.=20 > However, I=20 > > > agree that this proposed capability may not be very=20 > useful initially=20 > > > because servers may not support it and clients may not be=20 > adaptable=20 > > > enough to take advantage. However, that could change in a=20 > few years=20 > > > as algorithms get smarter. For example, it would probably=20 > be quite=20 > > > simple to perform some of the calculations in non-real time - e.g. > > > associate each cell ID with a single PSAP URI and confidence level > > > - and > > > perform a simple lookup in real time. If the capability is not=20 > > > allowed, then it won't be possible (or at least not so=20 > > > straightforward) to improve call setup time and routing=20 > reliability=20 > > > - which would be a pity. > > > > > > Brian's comments: I agree that one input could be a hard edged=20 > > > polygon in which case (if a uniform probability distribution is=20 > > > assumed), the resulting confidence is just the=20 > proportional overlap=20 > > > with the PSAP coverage area. For some positioning methods (e.g.=20 > > > yielding other shapes), a probability distribution can be=20 > assumed in=20 > > > which case the calculation of the confidence would be=20 > more complex=20 > > > (but still possible). The LoST response can remain deterministic=20 > > > (assuming "perfect > > > algorithms") as long as the allowed geographic shape inputs are=20 > > > defined carefully enough (e.g. state any default confidence level=20 > > > and/or probability distribution). This is not to say that=20 > different=20 > > > algorithms (or possibly even different implementations of=20 > the same=20 > > > algorithm) would always yield the same results - in fact, due to=20 > > > approximations, programming errors and shortcuts etc.=20 > they probably=20 > > > would not no matter how simple you make the protocol definition=20 > > > (e.g. consider a point input exactly on a PSAP boundary). > > > > > > Henning's comments: you seem to be saying that cell-sector based=20 > > > location estimates will typically cause routing errors=20 > whereas with=20 > > > more accurate (E911 phase 2 type) location, any routing error=20 > > > (considering that the terminal will be very close to the=20 > destination=20 > > > PSAP's coverage > > > area) will not be important. I have a somewhat different=20 > view though=20 > > > based on similar premises. For a given geographic area location=20 > > > input L, consider 2 possible results: (a) L is within one PSAP's=20 > > > coverage area with a confidence level >=3DX (e.g. X =3D 90%); (b) = L=20 > > > spans >=3D2 PSAP areas with a confidence level > > (a) occurs with significant frequency when L is cell-sector based=20 > > > (which I would find hard to doubt given the large numbers=20 > of small=20 > > > urban cells and some large PSAP coverage areas), then using=20 > > > cell-sector as an initial input could be sensible. For (b), there=20 > > > may be value in obtaining more accurate location=20 > information because=20 > > > the smaller the size of L, the higher will be the=20 > incidence of (a).=20 > > > (b) will still occur sometimes no matter how small L=20 > becomes (unless=20 > > > a point), but then the argument that any resulting=20 > routing error is=20 > > > less important comes to the rescue and you end up with a=20 > methodology=20 > > > that can both reduce call delay and improve routing reliability.=20 > > > (Note concerning Monte Carlo sampling by the > > > client: I agree that is one solution but rather inefficient, also=20 > > > complex for the client.) > > > > > > I look forward to more comments which hopefully can progress this. > > > > > > Kind Regards > > > > > > Stephen > > > -----Original Message----- > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > Sent: Tuesday, September 26, 2006 5:26 AM > > > To: Brian Rosen > > > Cc: Edge, Stephen; ECRIT > > > Subject: Re: [Ecrit] Indication of PSAP Confidence Level=20 > in a LoST=20 > > > QueryResponse > > > > > > I'll also add that earlier discussion has yielded the=20 > insight that=20 > > > sector-size areas are pretty useless for call routing, as=20 > there is a=20 > > > significant probability of mis-routes. > > > > > > This probability won't be reduced all that much by fancy area=20 > > > maximization techniques or anything else since you simply=20 > can't tell=20 > > > which of the PSAP serving areas you're in. With area=20 > maximization,=20 > > > for example, users in a cell sector will simply be assigned to=20 > > > whatever PSAP service area dominates the cell sector. On average,=20 > > > across cell towers, that will still make it a 50/50 toss-up. > > > > > > For dispatch, mid-sized areas of uncertainty are useful,=20 > > > corresponding to the typical FCC-compliant uncertainty=20 > regions of a=20 > > > few hundred feet. However, worrying that such areas span multiple=20 > > > PSAPs and then trying to pick the right one seems rather=20 > pointless=20 > > > (sorry...), given the complexity. (If clients really=20 > care, they can=20 > > > randomly sample the area, essentially doing a Monte-Carlo=20 > > > simulation, which will yield an area maximization by design.) > > > > > > Thus, I just don't see the benefit. Either the area of=20 > uncertainty=20 > > > is too large for routing, as it is for tower/face=20 > information, or it=20 > > > is too small to worry about the right PSAP, and can be=20 > treated as a=20 > > > point for PSAP selection purposes. > > > > > > > > > Henning > > > > > > On Sep 26, 2006, at 7:28 AM, Brian Rosen wrote: > > > > > >> I'm not sure I understand what you are proposing. The service=20 > > >> boundaries are hard edged polygons. If you put a point=20 > in, you get=20 > > >> an exact answer out. If you put a shape in, then we could have=20 > > >> some kind of overlap of the boundary polygons with the=20 > shape, and=20 > > >> get uncertainty from that. > > >> Is that > > >> what you were proposing? > > >> > > >> If so, I think I would support some kind of output that told you=20 > > >> how close of a fit we got. If that's not it, perhaps you would=20 > > >> explain in more detail what you propose. > > >> > > >> I do think we are pushing for the LoST resolver to be simple and=20 > > >> deterministic. The reason is that it is not in a position to=20 > > >> understand what the tradeoffs are. In general, the=20 > closer you get=20 > > >> to the origin of the location information, the more you=20 > understand=20 > > >> what is actually happening on the ground. We want=20 > earlier elements=20 > > >> to make the decisions, and not later elements. Thus we=20 > insist that=20 > > >> if you have more than one location, the client chooses,=20 > and not the=20 > > >> server. If we force the client to interpret inexactness, then I=20 > > >> think giving it as much information to make the choice=20 > as we can is=20 > > >> a useful thing to do. > > >> > > >> Brian > > >> > > >>> -----Original Message----- > > >>> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > > >>> Sent: Tuesday, September 26, 2006 2:58 AM > > >>> To: Edge, Stephen; ecrit@ietf.org > > >>> Subject: RE: [Ecrit] Indication of PSAP Confidence=20 > Level in a LoST=20 > > >>> QueryResponse > > >>> > > >>> Hi Stephen, > > >>> > > >>> I must admit, that I can't see any tangible benefits for this=20 > > >>> right now - that is probably going to be the biggest=20 > point leveled=20 > > >>> against this proposal. > > >>> > > >>> These sorts of discussion have been run in the past. =20 > Consider the=20 > > >>> discussions on whether or not uncertainty should be included in=20 > > >>> LoST (check the archives; it was in the last few weeks). And=20 > > >>> GEOPRIV have discussed confidence on the past, and aside from=20 > > >>> problems with people understanding the concepts, the main point=20 > > >>> against its inclusion was the lack of perceived benefit. > > >>> > > >>> You are probably correct, in that we don't know today=20 > how we could=20 > > >>> benefit from things like uncertainty and confidence in=20 > the future. > > >>> Certainly, > > >>> there is wisdom in drawing a line and saying "Ware Ye, Here Be=20 > > >>> Dragons". > > >>> Even if you know that there are people living on the=20 > other side of=20 > > >>> that line happily, you can get on with your business, which is=20 > > >>> engineering workable solutions. > > >>> > > >>> I suspect that this is primarily because people have=20 > trouble with=20 > > >>> the vagaries inherent in mobile and wireless systems. =20 > For LoST,=20 > > >>> in the here and now, what you are asking for is a small=20 > change in=20 > > >>> the underlying philosophy. This philosophy isn't necessarily=20 > > >>> written down, but you will find that this WG is currently=20 > > >>> operating under the assumption that its inputs will be simple. =20 > > >>> This gives solid, repeatable results; you can write=20 > algorithms to=20 > > >>> that; and almost anyone can get it right. > > >>> Having one > > >>> result is nice - we don't want request forking, which is a=20 > > >>> possibility unless you have a clear one-to-one mapping from=20 > > >>> location to URI... > > >>> > > >>> location -> FG -> FG (-> FG ...) -> Tree -> URI > > >>> > > >>> You understand the vagaries, and are comfortable with them, but=20 > > >>> these scare the willies out of most people - because=20 > you don't get=20 > > >>> results in nice tidy boxes. It's also harder to design=20 > a system=20 > > >>> that deals with fuzzy inputs. To start with, you need a really=20 > > >>> compelling reason to do it. Then, you need to make it=20 > so easy to=20 > > >>> do that not doing it would seem recalcitrant. > > >>> > > >>> I personally like the idea of building in a little=20 > tolerance into=20 > > >>> the whole system. And being able to convey this sort of=20 > > >>> information could be useful outside of an emergency=20 > situation as a=20 > > >>> sort of tuning mechanism. > > >>> Certainly, it would be useful in combination with location=20 > > >>> uncertainty and confidence to know whether or not=20 > current location=20 > > >>> information is adequate. > > >>> > > >>> But this is from the person that reminded GEOPRIV that location=20 > > >>> isn't always a simple point in space. > > >>> > > >>> Cheers, > > >>> Martin > > >>> > > >>> ________________________________________ > > >>> From: Edge, Stephen [mailto:sedge@qualcomm.com] > > >>> Sent: Tuesday, 26 September 2006 2:36 PM > > >>> To: ecrit@ietf.org > > >>> Subject: [Ecrit] Indication of PSAP Confidence Level in a LoST=20 > > >>> Query Response > > >>> > > >>> Hi All > > >>> Here is a topic that may or may not be new but maybe not yet=20 > > >>> presented in this light. In the not so distant future and=20 > > >>> certainly within the possible lifetime of the LoST=20 > capability, it=20 > > >>> may be possible using new algorithms and additional=20 > processing and=20 > > >>> storage availability to determine the probability that a=20 > > >>> particular PSAP URI is the correct one for a provided=20 > geographic=20 > > >>> or civil location (taking account of the fact that any provided=20 > > >>> location will often include, implicitly or explicitly,=20 > some area=20 > > >>> of uncertainty). This capability is possible in principle even=20 > > >>> today; it is just that the required amount of processing and=20 > > >>> storage may be too high (or the ability of currently known=20 > > >>> algorithms too low) to allow realistic and cost effective=20 > > >>> implementation. > > >>> > > >>> Assuming that a probability value, AKA confidence level, was=20 > > >>> provided in a LoST response, it would be possible with some=20 > > >>> solutions being developed (e.g. 3GPP and maybe 3GPP2)=20 > to obtain a=20 > > >>> more exact location for a wireless (or maybe wireline)=20 > user if the=20 > > >>> confidence value was not high and no significant delay had yet=20 > > >>> been expended to obtain the initial location. > > >>> That would then allow a second LoST query with a higher=20 > > >>> probability of success. It would also permit a network to=20 > > >>> instigate the initial LoST query using simple location=20 > information=20 > > >>> such as cell ID requiring no time to obtain. The overall result=20 > > >>> could be significantly lower call delay wherever an initial=20 > > >>> location mapped unambiguously to a single PSAP URI and more=20 > > >>> reliable routing for callers in PSAP border areas. > > >>> > > >>> This capability may seem strange in a wireline=20 > environment where a=20 > > >>> terminal would typically stay put for extended periods of time=20 > > >>> allowing plenty of opportunity to obtain a location before an=20 > > >>> emergency call was originated. But in a wireless=20 > environment, it=20 > > >>> can be practically impossible to know location with=20 > anything but=20 > > >>> very coarse accuracy at any arbitrary point in time and=20 > the time=20 > > >>> needed to obtain a location more accurately can be=20 > significant. It=20 > > >>> should also be noted that such an enhancement to LoST could be=20 > > >>> mostly independent of the means used to obtain location=20 > (whether=20 > > >>> for the first or second query). In other words, such a=20 > capability=20 > > >>> need not (greatly) prejudice issues relating to the=20 > architecture,=20 > > >>> procedures and methods used to obtain location. > > >>> > > >>> Of course, such an enhancement to LoST might be added=20 > later after=20 > > >>> it was well established that algorithms and computational=20 > > >>> capability would be up to the task. But the addition of=20 > an extra=20 > > >>> optional parameter to a LoST response need not impact=20 > > >>> implementations that choose not to use it (either as a=20 > client or=20 > > >>> server). And later implementation support would be=20 > easier because=20 > > >>> it would not require any new standards change. (Of course,=20 > > >>> proprietary support would always be possible, but potentially=20 > > >>> dangerous because of the risk of LoST evolution in some other=20 > > >>> direction, such as provision of more than one PSAP URI.) > > >>> > > >>> One possible consequence of this proposal might be to encourage=20 > > >>> non- uniformity in the algorithms used to convert=20 > location to PSAP=20 > > >>> URI - meaning different implementations could=20 > occasionally deliver=20 > > >>> different URIs (and different confidence levels) for the same=20 > > >>> location input and same PSAP database map. But I wonder if this=20 > > >>> should really be an issue - e.g. it may well turn out that some=20 > > >>> algorithms are better (more reliable, faster etc.) than=20 > others and=20 > > >>> that a demonstration of this in a live environment=20 > would be a good=20 > > >>> way to ensure that the better ones eventually become=20 > the ones most=20 > > >>> widely adopted. > > >>> > > >>> Anyhow, please comment on this. > > >>> Kind Regards > > >>> Stephen > > >>>=20 > ------------------------------------------------------------------ > > >>> -- > >=20 > > >>> - > > > > > >>> ----- > > >>> ---------------------- > > >>> This message is for the designated recipient only and=20 > may contain=20 > > >>> privileged, proprietary, or otherwise private information. > > >>> If you have received it in error, please notify the sender=20 > > >>> immediately and delete the original. Any unauthorized=20 > use of this=20 > > >>> email is prohibited. > > >>>=20 > ------------------------------------------------------------------ > > >>> -- > >=20 > > >>> - > > > > > >>> ----- > > >>> ---------------------- > > >>> [mf2] > > >> > > >> > > >> _______________________________________________ > > >> Ecrit mailing list > > >> Ecrit@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/ecrit > > > >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 27 19:30:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSiqa-000278-ER; Wed, 27 Sep 2006 19:29:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSiqZ-00023B-38 for ecrit@ietf.org; Wed, 27 Sep 2006 19:29:47 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSiqY-0004Rk-15 for ecrit@ietf.org; Wed, 27 Sep 2006 19:29:47 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k8RNTDWD008944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 27 Sep 2006 16:29:14 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k8RNTB23020306; Wed, 27 Sep 2006 16:29:12 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Sep 2006 16:29:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Indication of PSAP Confidence Level in a LoSTQueryResponse Date: Wed, 27 Sep 2006 16:29:17 -0700 Message-ID: <21A52261514BE844AB662C1C21A29EA928979D@NAEX13.na.qualcomm.com> In-Reply-To: <5D1A7985295922448D5550C94DE291804E31CC@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Indication of PSAP Confidence Level in a LoSTQueryResponse thread-index: Acbh16UKFMGg2o6IR+iaxBlT2KdcAwACn8oQABGgsCAAA4iNEAAU0MrQ From: "Edge, Stephen" To: "Drage, Keith \(Keith\)" , "Brian Rosen" , "Henning Schulzrinne" X-OriginalArrivalTime: 27 Sep 2006 23:29:10.0076 (UTC) FILETIME=[BBCDBFC0:01C6E28C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f9ac37b081a3249085c4867ee1404d4 Cc: ECRIT , "Thomson, Martin" 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: , Errors-To: ecrit-bounces@ietf.org Hi Brian, others It's not clear if NENA are endorsing cell-sector routing or just = simplifying how it should operate. If the former, I can't help = commenting that cell-sector routing did not last very long for circuit = mode since, soon after initially deployments and under pressure from the = PSAPs, so called "interim positioning" was added to 3GPP and J-STD-036 = spec.s. If IP based emergency call support goes the same way, the issue = of performing more accurate positioning on a possibly selective basis = (and at some cost in extra delay) will surely re-arise. I also agree with Keith on the worldwide aspect - though up until now, = NA seems to have monopolized the most stringent requirements. Kind Regards Stephen -----Original Message----- From: Drage, Keith (Keith) [mailto:drage@lucent.com]=20 Sent: Wednesday, September 27, 2006 9:14 AM To: Brian Rosen; Edge, Stephen; Henning Schulzrinne Cc: ECRIT; Thomson, Martin Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a = LoSTQueryResponse Some of the terms like "anywhere" are very general. I am unclear whether = you are giving a response based on NENA knowledge or a wider knowledge. Remember the scope of ECRIT is to cover worldwide requirements, not just = NAR. Can you rephrase you answer in terms of the geographical areas = where you believe this is the answer, thus therefore identifying those = regions where you do not have knowledge of the answer. Regards Keith=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: 27 September 2006 12:42 > To: 'Edge, Stephen'; 'Henning Schulzrinne' > Cc: 'ECRIT'; 'Thomson, Martin' > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a=20 > LoSTQueryResponse >=20 > A while ago, we had a discussion of whether there was a need=20 > to express cell site and sector as an input format to LoST. =20 > I took an action to ask NENA. > The "official" answer is not yet available, but unofficially,=20 > I can state that there was no support for this idea anywhere. =20 >=20 > In fact, there was no support for representing cell site and=20 > sector by anything except a point, which might be a civic or=20 > a geo. The reality is that the PSAPs and the wireless=20 > carriers get together and DECIDE which PSAP gets calls from=20 > each cell site/sector. Although there are frequent changes=20 > in the tower arrangements, it seems there is a choice made=20 > who gets the call. Picking a point that lies within the=20 > desired PSAP boundary seems to be a very acceptable mechanism. >=20 > Now, I think this is somewhat na=EFve, based on current=20 > experience, and may need to be revisited as technology=20 > evolves. However, we asked the question of the experts, and=20 > that's what they said they wanted. In this case, we had=20 > significant wireless carrier and PSAP participation in the discussion. >=20 > Although "quick fix" technology is getting better, and more=20 > prevalent, and proliferation of location based services means=20 > more of the mechanism is "turned on" all the time, most calls=20 > emergency calls are still routed by cell site/sector. More=20 > accurate information is obtained much later in the call (15=20 > seconds is a typical number). Representing this location as=20 > a point is the current answer, and I think that's all we=20 > should do now, even though I personally think we will need more. >=20 > Brian >=20 > > -----Original Message----- > > From: Edge, Stephen [mailto:sedge@qualcomm.com] > > Sent: Wednesday, September 27, 2006 12:38 AM > > To: Henning Schulzrinne > > Cc: Brian Rosen; Thomson, Martin; ECRIT > > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a LoST=20 > > QueryResponse > >=20 > > Hi Henning > >=20 > > Thanks for the further comments. I appreciate the points=20 > you are making. > >=20 > > For many wireless networks (e.g. 3GPP UMTS, cdma2000), a=20 > cell-sector=20 > > ID is all the network may generally receive from a terminal=20 > inside a=20 > > SIP INVITE - since any more accurate location may cost too much in=20 > > time (e.g. might not be associated by the network with an emergency=20 > > call and hence not assigned priority status). With the 3GPP current=20 > > architecture > > (3GPP2 has not yet decided one), this will be passed to an=20 > E-CSCF in=20 > > the serving network and thence to an LRF (Location=20 > Retrieval Function)=20 > > for use in deriving the PSAP URI. The LRF may be able to instigate=20 > > more accurate location (e.g. using a user plane location=20 > solution like=20 > > SUPL or using the 3GPP control plane solution) but this=20 > will take time=20 > > and resources. If it turns out that the cell-sector ID maps=20 > to a PSAP=20 > > URI with high confidence in a majority of cases, there=20 > would seem to=20 > > be some benefit in performing this mapping rather than adding extra=20 > > delay by attempting to obtain a more accurate location.=20 > Note that this=20 > > is now an issue of call delay just as much as routing reliability=20 > > which may be significant so long as legacy PSAPs have to be=20 > supported=20 > > and there is delay on both the packet and circuit mode=20 > sides as well=20 > > as in providing the interworking. > >=20 > > I should also point out that the proposed capability is=20 > generally not=20 > > possible for circuit mode wireless calls because the control points=20 > > for location and routing are separate. Using the same control point=20 > > for both functions allows an improvement (in terms of resource=20 > > efficiency, call delay and routing reliability) over=20 > circuit mode that=20 > > could provide a better service. > >=20 > > I agree that removing unnecessary complexity from the service and=20 > > server is worthwhile but I am not sure that an optional capability=20 > > that can be omitted initially should count very heavily.=20 > For example,=20 > > it is possible that algorithms that reliably deliver the=20 > most probable=20 > > PSAP destination (I mean the truly most probable one and not an=20 > > approximation based on centroids or other approximate data)=20 > will need=20 > > the capability to compute some confidence measure anyway as=20 > part of the selection process. > >=20 > > I suppose one conclusion of this discussion (given the direction in=20 > > which it seems headed) would be to leave out this=20 > capability initially=20 > > and then, based on actual call delay and routing results,=20 > reconsider=20 > > it or something similar later if needed. > >=20 > > Kind Regards > >=20 > > Stephen > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Tuesday, September 26, 2006 6:52 PM > > To: Edge, Stephen > > Cc: Brian Rosen; Thomson, Martin; ECRIT > > Subject: Re: [Ecrit] Indication of PSAP Confidence Level in a LoST=20 > > QueryResponse > >=20 > > Stephen, > >=20 > > any engineering is a trade-off between functionality and complexity. > > Speaking from some experience, I so far have always regretted when=20 > > erring on the side of complexity, on the "it could be=20 > useful" theory. > > I have no intention of repeating this mistake for LoST,=20 > particularly=20 > > for a truly mission-critical system. > >=20 > > You probably would want to review the list discussion as to why I=20 > > believe any marginal increase in "correct" routing is just=20 > not worth=20 > > the tremendous cost in overall system complexity and=20 > unpredictability.=20 > > I won't bore the rest of the list by repeating these. > >=20 > > I just don't see cell sector as useful, long term, so=20 > whether it could=20 > > actually work in some large number of cases is rather immaterial.=20 > > Since we know that it will fail, regardless of probability=20 > routing or=20 > > not, in an unacceptably large number of cases, it seems=20 > much better to=20 > > design a system that actually works, particularly given that the=20 > > technology is available and now standard on most modern=20 > cell phones.=20 > > Old cell phone systems won't be running LoST anyway. > >=20 > > I have to admit that I find it rather uninteresting whether=20 > I call the=20 > > wrong PSAP if I'm 100 ft from the border of the PSAP. =20 > You'll always=20 > > have cases where the initial route goes to PSAP A, but the caller=20 > > moves to PSAP B while talking to the call taker. In the=20 > town I live,=20 > > it probably takes about 2 minutes, at 30 mph, to cross the PSAP=20 > > coverage area. Within that range, I'm also just as likely=20 > to report on=20 > > an incident on the other side of the town border. Again, lots of=20 > > complexity for no operational gain. > >=20 > > While it is theoretically possible, with some very low=20 > probability, to=20 > > end up exactly on the border between two PSAPs, in that=20 > case, it just=20 > > doesn't matter what happens and whether two implementations do the=20 > > same thing. By definition, either PSAP is as good the other. > >=20 > > In those rare cases where the client cares, it can do the=20 > > probabilistic computation. I'd rather have those that care, pay the=20 > > cost, rather than everyone. > >=20 > > Henning > >=20 > > On Sep 26, 2006, at 9:28 PM, Edge, Stephen wrote: > >=20 > > > Hi All > > > > > > Thanks for the comments (Martin, Brian, Henning). Though not too=20 > > > encouraging so far, here are a few responses. > > > > > > Martin's comments: I am not proposing including=20 > > > confidence/probability information in the LoST query (just a=20 > > > geographic shape would do) although I believe it would help. My=20 > > > proposal is just to allow optional addition of a confidence value=20 > > > associated with a single PSAP URI result in the LoST=20 > response. That=20 > > > way the call server knows the likelihood of misrouting=20 > (e.g. in some=20 > > > cases could be 50% or higher). If it turns out that the=20 > chosen PSAP=20 > > > is not even E911 phase 2 capable, there could be a major=20 > problem in=20 > > > rerouting to the correct PSAP because the initially=20 > chosen PSAP will=20 > > > not be able to receive a more accurate location estimate.=20 > However, I=20 > > > agree that this proposed capability may not be very=20 > useful initially=20 > > > because servers may not support it and clients may not be=20 > adaptable=20 > > > enough to take advantage. However, that could change in a=20 > few years=20 > > > as algorithms get smarter. For example, it would probably=20 > be quite=20 > > > simple to perform some of the calculations in non-real time - e.g. > > > associate each cell ID with a single PSAP URI and confidence level > > > - and > > > perform a simple lookup in real time. If the capability is not=20 > > > allowed, then it won't be possible (or at least not so=20 > > > straightforward) to improve call setup time and routing=20 > reliability=20 > > > - which would be a pity. > > > > > > Brian's comments: I agree that one input could be a hard edged=20 > > > polygon in which case (if a uniform probability distribution is=20 > > > assumed), the resulting confidence is just the=20 > proportional overlap=20 > > > with the PSAP coverage area. For some positioning methods (e.g.=20 > > > yielding other shapes), a probability distribution can be=20 > assumed in=20 > > > which case the calculation of the confidence would be=20 > more complex=20 > > > (but still possible). The LoST response can remain deterministic=20 > > > (assuming "perfect > > > algorithms") as long as the allowed geographic shape inputs are=20 > > > defined carefully enough (e.g. state any default confidence level=20 > > > and/or probability distribution). This is not to say that=20 > different=20 > > > algorithms (or possibly even different implementations of=20 > the same=20 > > > algorithm) would always yield the same results - in fact, due to=20 > > > approximations, programming errors and shortcuts etc.=20 > they probably=20 > > > would not no matter how simple you make the protocol definition=20 > > > (e.g. consider a point input exactly on a PSAP boundary). > > > > > > Henning's comments: you seem to be saying that cell-sector based=20 > > > location estimates will typically cause routing errors=20 > whereas with=20 > > > more accurate (E911 phase 2 type) location, any routing error=20 > > > (considering that the terminal will be very close to the=20 > destination=20 > > > PSAP's coverage > > > area) will not be important. I have a somewhat different=20 > view though=20 > > > based on similar premises. For a given geographic area location=20 > > > input L, consider 2 possible results: (a) L is within one PSAP's=20 > > > coverage area with a confidence level >=3DX (e.g. X =3D 90%); (b) = L=20 > > > spans >=3D2 PSAP areas with a confidence level > > (a) occurs with significant frequency when L is cell-sector based=20 > > > (which I would find hard to doubt given the large numbers=20 > of small=20 > > > urban cells and some large PSAP coverage areas), then using=20 > > > cell-sector as an initial input could be sensible. For (b), there=20 > > > may be value in obtaining more accurate location=20 > information because=20 > > > the smaller the size of L, the higher will be the=20 > incidence of (a).=20 > > > (b) will still occur sometimes no matter how small L=20 > becomes (unless=20 > > > a point), but then the argument that any resulting=20 > routing error is=20 > > > less important comes to the rescue and you end up with a=20 > methodology=20 > > > that can both reduce call delay and improve routing reliability.=20 > > > (Note concerning Monte Carlo sampling by the > > > client: I agree that is one solution but rather inefficient, also=20 > > > complex for the client.) > > > > > > I look forward to more comments which hopefully can progress this. > > > > > > Kind Regards > > > > > > Stephen > > > -----Original Message----- > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > Sent: Tuesday, September 26, 2006 5:26 AM > > > To: Brian Rosen > > > Cc: Edge, Stephen; ECRIT > > > Subject: Re: [Ecrit] Indication of PSAP Confidence Level=20 > in a LoST=20 > > > QueryResponse > > > > > > I'll also add that earlier discussion has yielded the=20 > insight that=20 > > > sector-size areas are pretty useless for call routing, as=20 > there is a=20 > > > significant probability of mis-routes. > > > > > > This probability won't be reduced all that much by fancy area=20 > > > maximization techniques or anything else since you simply=20 > can't tell=20 > > > which of the PSAP serving areas you're in. With area=20 > maximization,=20 > > > for example, users in a cell sector will simply be assigned to=20 > > > whatever PSAP service area dominates the cell sector. On average,=20 > > > across cell towers, that will still make it a 50/50 toss-up. > > > > > > For dispatch, mid-sized areas of uncertainty are useful,=20 > > > corresponding to the typical FCC-compliant uncertainty=20 > regions of a=20 > > > few hundred feet. However, worrying that such areas span multiple=20 > > > PSAPs and then trying to pick the right one seems rather=20 > pointless=20 > > > (sorry...), given the complexity. (If clients really=20 > care, they can=20 > > > randomly sample the area, essentially doing a Monte-Carlo=20 > > > simulation, which will yield an area maximization by design.) > > > > > > Thus, I just don't see the benefit. Either the area of=20 > uncertainty=20 > > > is too large for routing, as it is for tower/face=20 > information, or it=20 > > > is too small to worry about the right PSAP, and can be=20 > treated as a=20 > > > point for PSAP selection purposes. > > > > > > > > > Henning > > > > > > On Sep 26, 2006, at 7:28 AM, Brian Rosen wrote: > > > > > >> I'm not sure I understand what you are proposing. The service=20 > > >> boundaries are hard edged polygons. If you put a point=20 > in, you get=20 > > >> an exact answer out. If you put a shape in, then we could have=20 > > >> some kind of overlap of the boundary polygons with the=20 > shape, and=20 > > >> get uncertainty from that. > > >> Is that > > >> what you were proposing? > > >> > > >> If so, I think I would support some kind of output that told you=20 > > >> how close of a fit we got. If that's not it, perhaps you would=20 > > >> explain in more detail what you propose. > > >> > > >> I do think we are pushing for the LoST resolver to be simple and=20 > > >> deterministic. The reason is that it is not in a position to=20 > > >> understand what the tradeoffs are. In general, the=20 > closer you get=20 > > >> to the origin of the location information, the more you=20 > understand=20 > > >> what is actually happening on the ground. We want=20 > earlier elements=20 > > >> to make the decisions, and not later elements. Thus we=20 > insist that=20 > > >> if you have more than one location, the client chooses,=20 > and not the=20 > > >> server. If we force the client to interpret inexactness, then I=20 > > >> think giving it as much information to make the choice=20 > as we can is=20 > > >> a useful thing to do. > > >> > > >> Brian > > >> > > >>> -----Original Message----- > > >>> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > > >>> Sent: Tuesday, September 26, 2006 2:58 AM > > >>> To: Edge, Stephen; ecrit@ietf.org > > >>> Subject: RE: [Ecrit] Indication of PSAP Confidence=20 > Level in a LoST=20 > > >>> QueryResponse > > >>> > > >>> Hi Stephen, > > >>> > > >>> I must admit, that I can't see any tangible benefits for this=20 > > >>> right now - that is probably going to be the biggest=20 > point leveled=20 > > >>> against this proposal. > > >>> > > >>> These sorts of discussion have been run in the past. =20 > Consider the=20 > > >>> discussions on whether or not uncertainty should be included in=20 > > >>> LoST (check the archives; it was in the last few weeks). And=20 > > >>> GEOPRIV have discussed confidence on the past, and aside from=20 > > >>> problems with people understanding the concepts, the main point=20 > > >>> against its inclusion was the lack of perceived benefit. > > >>> > > >>> You are probably correct, in that we don't know today=20 > how we could=20 > > >>> benefit from things like uncertainty and confidence in=20 > the future. > > >>> Certainly, > > >>> there is wisdom in drawing a line and saying "Ware Ye, Here Be=20 > > >>> Dragons". > > >>> Even if you know that there are people living on the=20 > other side of=20 > > >>> that line happily, you can get on with your business, which is=20 > > >>> engineering workable solutions. > > >>> > > >>> I suspect that this is primarily because people have=20 > trouble with=20 > > >>> the vagaries inherent in mobile and wireless systems. =20 > For LoST,=20 > > >>> in the here and now, what you are asking for is a small=20 > change in=20 > > >>> the underlying philosophy. This philosophy isn't necessarily=20 > > >>> written down, but you will find that this WG is currently=20 > > >>> operating under the assumption that its inputs will be simple. =20 > > >>> This gives solid, repeatable results; you can write=20 > algorithms to=20 > > >>> that; and almost anyone can get it right. > > >>> Having one > > >>> result is nice - we don't want request forking, which is a=20 > > >>> possibility unless you have a clear one-to-one mapping from=20 > > >>> location to URI... > > >>> > > >>> location -> FG -> FG (-> FG ...) -> Tree -> URI > > >>> > > >>> You understand the vagaries, and are comfortable with them, but=20 > > >>> these scare the willies out of most people - because=20 > you don't get=20 > > >>> results in nice tidy boxes. It's also harder to design=20 > a system=20 > > >>> that deals with fuzzy inputs. To start with, you need a really=20 > > >>> compelling reason to do it. Then, you need to make it=20 > so easy to=20 > > >>> do that not doing it would seem recalcitrant. > > >>> > > >>> I personally like the idea of building in a little=20 > tolerance into=20 > > >>> the whole system. And being able to convey this sort of=20 > > >>> information could be useful outside of an emergency=20 > situation as a=20 > > >>> sort of tuning mechanism. > > >>> Certainly, it would be useful in combination with location=20 > > >>> uncertainty and confidence to know whether or not=20 > current location=20 > > >>> information is adequate. > > >>> > > >>> But this is from the person that reminded GEOPRIV that location=20 > > >>> isn't always a simple point in space. > > >>> > > >>> Cheers, > > >>> Martin > > >>> > > >>> ________________________________________ > > >>> From: Edge, Stephen [mailto:sedge@qualcomm.com] > > >>> Sent: Tuesday, 26 September 2006 2:36 PM > > >>> To: ecrit@ietf.org > > >>> Subject: [Ecrit] Indication of PSAP Confidence Level in a LoST=20 > > >>> Query Response > > >>> > > >>> Hi All > > >>> Here is a topic that may or may not be new but maybe not yet=20 > > >>> presented in this light. In the not so distant future and=20 > > >>> certainly within the possible lifetime of the LoST=20 > capability, it=20 > > >>> may be possible using new algorithms and additional=20 > processing and=20 > > >>> storage availability to determine the probability that a=20 > > >>> particular PSAP URI is the correct one for a provided=20 > geographic=20 > > >>> or civil location (taking account of the fact that any provided=20 > > >>> location will often include, implicitly or explicitly,=20 > some area=20 > > >>> of uncertainty). This capability is possible in principle even=20 > > >>> today; it is just that the required amount of processing and=20 > > >>> storage may be too high (or the ability of currently known=20 > > >>> algorithms too low) to allow realistic and cost effective=20 > > >>> implementation. > > >>> > > >>> Assuming that a probability value, AKA confidence level, was=20 > > >>> provided in a LoST response, it would be possible with some=20 > > >>> solutions being developed (e.g. 3GPP and maybe 3GPP2)=20 > to obtain a=20 > > >>> more exact location for a wireless (or maybe wireline)=20 > user if the=20 > > >>> confidence value was not high and no significant delay had yet=20 > > >>> been expended to obtain the initial location. > > >>> That would then allow a second LoST query with a higher=20 > > >>> probability of success. It would also permit a network to=20 > > >>> instigate the initial LoST query using simple location=20 > information=20 > > >>> such as cell ID requiring no time to obtain. The overall result=20 > > >>> could be significantly lower call delay wherever an initial=20 > > >>> location mapped unambiguously to a single PSAP URI and more=20 > > >>> reliable routing for callers in PSAP border areas. > > >>> > > >>> This capability may seem strange in a wireline=20 > environment where a=20 > > >>> terminal would typically stay put for extended periods of time=20 > > >>> allowing plenty of opportunity to obtain a location before an=20 > > >>> emergency call was originated. But in a wireless=20 > environment, it=20 > > >>> can be practically impossible to know location with=20 > anything but=20 > > >>> very coarse accuracy at any arbitrary point in time and=20 > the time=20 > > >>> needed to obtain a location more accurately can be=20 > significant. It=20 > > >>> should also be noted that such an enhancement to LoST could be=20 > > >>> mostly independent of the means used to obtain location=20 > (whether=20 > > >>> for the first or second query). In other words, such a=20 > capability=20 > > >>> need not (greatly) prejudice issues relating to the=20 > architecture,=20 > > >>> procedures and methods used to obtain location. > > >>> > > >>> Of course, such an enhancement to LoST might be added=20 > later after=20 > > >>> it was well established that algorithms and computational=20 > > >>> capability would be up to the task. But the addition of=20 > an extra=20 > > >>> optional parameter to a LoST response need not impact=20 > > >>> implementations that choose not to use it (either as a=20 > client or=20 > > >>> server). And later implementation support would be=20 > easier because=20 > > >>> it would not require any new standards change. (Of course,=20 > > >>> proprietary support would always be possible, but potentially=20 > > >>> dangerous because of the risk of LoST evolution in some other=20 > > >>> direction, such as provision of more than one PSAP URI.) > > >>> > > >>> One possible consequence of this proposal might be to encourage=20 > > >>> non- uniformity in the algorithms used to convert=20 > location to PSAP=20 > > >>> URI - meaning different implementations could=20 > occasionally deliver=20 > > >>> different URIs (and different confidence levels) for the same=20 > > >>> location input and same PSAP database map. But I wonder if this=20 > > >>> should really be an issue - e.g. it may well turn out that some=20 > > >>> algorithms are better (more reliable, faster etc.) than=20 > others and=20 > > >>> that a demonstration of this in a live environment=20 > would be a good=20 > > >>> way to ensure that the better ones eventually become=20 > the ones most=20 > > >>> widely adopted. > > >>> > > >>> Anyhow, please comment on this. > > >>> Kind Regards > > >>> Stephen > > >>>=20 > ------------------------------------------------------------------ > > >>> -- > >=20 > > >>> - > > > > > >>> ----- > > >>> ---------------------- > > >>> This message is for the designated recipient only and=20 > may contain=20 > > >>> privileged, proprietary, or otherwise private information. > > >>> If you have received it in error, please notify the sender=20 > > >>> immediately and delete the original. Any unauthorized=20 > use of this=20 > > >>> email is prohibited. > > >>>=20 > ------------------------------------------------------------------ > > >>> -- > >=20 > > >>> - > > > > > >>> ----- > > >>> ---------------------- > > >>> [mf2] > > >> > > >> > > >> _______________________________________________ > > >> Ecrit mailing list > > >> Ecrit@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/ecrit > > > >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 27 19:35:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSiwJ-00065M-MC; Wed, 27 Sep 2006 19:35:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSiwI-000631-LK for ecrit@ietf.org; Wed, 27 Sep 2006 19:35:42 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSiwH-00054F-Ac for ecrit@ietf.org; Wed, 27 Sep 2006 19:35:42 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k8RNZTZh009650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 27 Sep 2006 16:35:31 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k8RNYjRH022623; Wed, 27 Sep 2006 16:35:29 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Sep 2006 16:34:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Indication of PSAP Confidence Level in a LoST QueryResponse Date: Wed, 27 Sep 2006 16:35:00 -0700 Message-ID: <21A52261514BE844AB662C1C21A29EA92897A0@NAEX13.na.qualcomm.com> In-Reply-To: <40663334-CCAA-4234-AFAC-FB4C79F90AD9@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Indication of PSAP Confidence Level in a LoST QueryResponse thread-index: AcbiNea03u6uWBQoS1eRvD+ZW9JW3wAVy4Jg From: "Edge, Stephen" To: "Henning Schulzrinne" X-OriginalArrivalTime: 27 Sep 2006 23:34:51.0005 (UTC) FILETIME=[870362D0:01C6E28D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Thanks for the answer. So for the time being, we drop the issue. I assume that forward compatibility (e.g. inclusion of optional unrecognized parameters in both a query and response) will be supported in the first version to ensure that such enhancements remain possible. Kind Regards Stephen -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Wednesday, September 27, 2006 6:07 AM To: Edge, Stephen Cc: ECRIT Subject: Re: [Ecrit] Indication of PSAP Confidence Level in a LoST QueryResponse > > I suppose one conclusion of this discussion (given the direction in > which it seems headed) would be to leave out this capability initially > and then, based on actual call delay and routing results, =20 > reconsider it > or something similar later if needed. I agree with that general conclusion; nothing in the design of LoST =20 prevents such an addition at a later time. As with any distributed =20 system with many components operated by different jurisdictions, =20 upgrading all components at the same time may well be difficult. One =20 possible solution, which is roughly in the spec right now but needs =20 some additional work, is to specify only a 3D-point as mandatory and =20 allow the inclusion of another "fancy" (some 3D) location object that =20 servers are free to ignore. That way, "old" or "simple" systems will =20 do roughly the right thing, without preventing advanced implementations. You don't want to get the situation that the first resolver doesn't =20 understand the new location object, and thus can't pass the request =20 to others (or, maybe worse, that some LoST server in the middle of a =20 referral chain chokes on the format). Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 27 19:47:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSj6q-0003tm-HS; Wed, 27 Sep 2006 19:46:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSj6o-0003th-R1 for ecrit@ietf.org; Wed, 27 Sep 2006 19:46:34 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSj6k-00078X-Nm for ecrit@ietf.org; Wed, 27 Sep 2006 19:46:34 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GSj6Z-0005I1-Ni; Wed, 27 Sep 2006 18:46:20 -0500 From: "Brian Rosen" To: "'Edge, Stephen'" , "'Drage, Keith \(Keith\)'" , "'Henning Schulzrinne'" Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a LoSTQueryResponse Date: Wed, 27 Sep 2006 19:46:24 -0400 Message-ID: <002801c6e28f$26a44ba0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <21A52261514BE844AB662C1C21A29EA928979D@NAEX13.na.qualcomm.com> thread-index: Acbh16UKFMGg2o6IR+iaxBlT2KdcAwACn8oQABGgsCAAA4iNEAAU0MrQAAC+ziA= X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a5294b34f62cf4aba63c62e30e627ff Cc: 'ECRIT' , "'Thomson, Martin'" 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: , Errors-To: ecrit-bounces@ietf.org The PSAPs would prefer to route on accurate data. It can be a = significant problem to have the call routed incorrectly because the only information known at the time the call was placed was cell/sector. NENA's position is that, with current technology, cell/sector may be all = the information there is. It's very clear they don't want to wait the 12-15 seconds to get accurate location before the call is routed. Therefore, = they reluctantly accept routing by cell/sector. Then you have the issue of, if you are routing by cell/sector, how you = do that. Again, NENA has a pragmatic answer: they decide, in advance, = which PSAP should get the call for a given cell/sector, and they choose a = point within the cell/sector that represents the location of that cell/sector which will route to the PSAP they want to get the call. What I said = above isn't strictly true in that the chosen point doesn't actually have to be within the cell/sector; it can be any point. I asked them if they would prefer, or would be interested in, = representing the cell/sector as a shape, rather than a point. Their answer (again, = this is North America, and really U.S.) was no, they wanted the = representation to be a point. The carrier maps cell/sector to a point, and uses the point = to choose a route. Summarizing, the preferred representation for the location of the CALLER = is a point. The technology forces you to say "point with uncertainty". If = you cannot, because of limitations in the technology, determine the point at = the time of the call, it is acceptable, if undesirable, to route based on = the cell/sector. The preferred method for routing based on cell/sector, according to this NENA group, is to map cell/sector to point, and then = use LoST to route based on that point. Just as an aside, the PSAPs have a real problem with uncertainty, = primarily because there is no way to represent the information to a call taker = when different carriers use different uncertainty values. Ask yourself what = you would like to see on a screen if you get one call with some location and = 70% uncertainty, and then immediately thereafter, get a call with the same location and 50% uncertainty, how do you want the screen to show the difference? While uncertainty is a fact of life in the real world, the = way we deal with it today is not meeting the need. The net result is that uncertainty is ignored, not a good answer, but so far, I have not heard = any proposal for a better answer. If all carriers used the same uncertainty values, then we might have a way to represent the information. If there = was an accurate conversion from one uncertainty value to another, that might = be useful, but I don't think any such thing exists. Brian > -----Original Message----- > From: Edge, Stephen [mailto:sedge@qualcomm.com] > Sent: Wednesday, September 27, 2006 7:29 PM > To: Drage, Keith (Keith); Brian Rosen; Henning Schulzrinne > Cc: ECRIT; Thomson, Martin > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a > LoSTQueryResponse >=20 > Hi Brian, others >=20 > It's not clear if NENA are endorsing cell-sector routing or just > simplifying how it should operate. If the former, I can't help = commenting > that cell-sector routing did not last very long for circuit mode = since, > soon after initially deployments and under pressure from the PSAPs, so > called "interim positioning" was added to 3GPP and J-STD-036 spec.s. = If IP > based emergency call support goes the same way, the issue of = performing > more accurate positioning on a possibly selective basis (and at some = cost > in extra delay) will surely re-arise. >=20 > I also agree with Keith on the worldwide aspect - though up until now, = NA > seems to have monopolized the most stringent requirements. >=20 > Kind Regards >=20 > Stephen > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Wednesday, September 27, 2006 9:14 AM > To: Brian Rosen; Edge, Stephen; Henning Schulzrinne > Cc: ECRIT; Thomson, Martin > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a > LoSTQueryResponse >=20 > Some of the terms like "anywhere" are very general. I am unclear = whether > you are giving a response based on NENA knowledge or a wider = knowledge. >=20 > Remember the scope of ECRIT is to cover worldwide requirements, not = just > NAR. Can you rephrase you answer in terms of the geographical areas = where > you believe this is the answer, thus therefore identifying those = regions > where you do not have knowledge of the answer. >=20 > Regards >=20 > Keith >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: 27 September 2006 12:42 > > To: 'Edge, Stephen'; 'Henning Schulzrinne' > > Cc: 'ECRIT'; 'Thomson, Martin' > > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a > > LoSTQueryResponse > > > > A while ago, we had a discussion of whether there was a need > > to express cell site and sector as an input format to LoST. > > I took an action to ask NENA. > > The "official" answer is not yet available, but unofficially, > > I can state that there was no support for this idea anywhere. > > > > In fact, there was no support for representing cell site and > > sector by anything except a point, which might be a civic or > > a geo. The reality is that the PSAPs and the wireless > > carriers get together and DECIDE which PSAP gets calls from > > each cell site/sector. Although there are frequent changes > > in the tower arrangements, it seems there is a choice made > > who gets the call. Picking a point that lies within the > > desired PSAP boundary seems to be a very acceptable mechanism. > > > > Now, I think this is somewhat na=EFve, based on current > > experience, and may need to be revisited as technology > > evolves. However, we asked the question of the experts, and > > that's what they said they wanted. In this case, we had > > significant wireless carrier and PSAP participation in the = discussion. > > > > Although "quick fix" technology is getting better, and more > > prevalent, and proliferation of location based services means > > more of the mechanism is "turned on" all the time, most calls > > emergency calls are still routed by cell site/sector. More > > accurate information is obtained much later in the call (15 > > seconds is a typical number). Representing this location as > > a point is the current answer, and I think that's all we > > should do now, even though I personally think we will need more. > > > > Brian > > > > > -----Original Message----- > > > From: Edge, Stephen [mailto:sedge@qualcomm.com] > > > Sent: Wednesday, September 27, 2006 12:38 AM > > > To: Henning Schulzrinne > > > Cc: Brian Rosen; Thomson, Martin; ECRIT > > > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a LoST > > > QueryResponse > > > > > > Hi Henning > > > > > > Thanks for the further comments. I appreciate the points > > you are making. > > > > > > For many wireless networks (e.g. 3GPP UMTS, cdma2000), a > > cell-sector > > > ID is all the network may generally receive from a terminal > > inside a > > > SIP INVITE - since any more accurate location may cost too much in > > > time (e.g. might not be associated by the network with an = emergency > > > call and hence not assigned priority status). With the 3GPP = current > > > architecture > > > (3GPP2 has not yet decided one), this will be passed to an > > E-CSCF in > > > the serving network and thence to an LRF (Location > > Retrieval Function) > > > for use in deriving the PSAP URI. The LRF may be able to instigate > > > more accurate location (e.g. using a user plane location > > solution like > > > SUPL or using the 3GPP control plane solution) but this > > will take time > > > and resources. If it turns out that the cell-sector ID maps > > to a PSAP > > > URI with high confidence in a majority of cases, there > > would seem to > > > be some benefit in performing this mapping rather than adding = extra > > > delay by attempting to obtain a more accurate location. > > Note that this > > > is now an issue of call delay just as much as routing reliability > > > which may be significant so long as legacy PSAPs have to be > > supported > > > and there is delay on both the packet and circuit mode > > sides as well > > > as in providing the interworking. > > > > > > I should also point out that the proposed capability is > > generally not > > > possible for circuit mode wireless calls because the control = points > > > for location and routing are separate. Using the same control = point > > > for both functions allows an improvement (in terms of resource > > > efficiency, call delay and routing reliability) over > > circuit mode that > > > could provide a better service. > > > > > > I agree that removing unnecessary complexity from the service and > > > server is worthwhile but I am not sure that an optional capability > > > that can be omitted initially should count very heavily. > > For example, > > > it is possible that algorithms that reliably deliver the > > most probable > > > PSAP destination (I mean the truly most probable one and not an > > > approximation based on centroids or other approximate data) > > will need > > > the capability to compute some confidence measure anyway as > > part of the selection process. > > > > > > I suppose one conclusion of this discussion (given the direction = in > > > which it seems headed) would be to leave out this > > capability initially > > > and then, based on actual call delay and routing results, > > reconsider > > > it or something similar later if needed. > > > > > > Kind Regards > > > > > > Stephen > > > -----Original Message----- > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > Sent: Tuesday, September 26, 2006 6:52 PM > > > To: Edge, Stephen > > > Cc: Brian Rosen; Thomson, Martin; ECRIT > > > Subject: Re: [Ecrit] Indication of PSAP Confidence Level in a LoST > > > QueryResponse > > > > > > Stephen, > > > > > > any engineering is a trade-off between functionality and = complexity. > > > Speaking from some experience, I so far have always regretted when > > > erring on the side of complexity, on the "it could be > > useful" theory. > > > I have no intention of repeating this mistake for LoST, > > particularly > > > for a truly mission-critical system. > > > > > > You probably would want to review the list discussion as to why I > > > believe any marginal increase in "correct" routing is just > > not worth > > > the tremendous cost in overall system complexity and > > unpredictability. > > > I won't bore the rest of the list by repeating these. > > > > > > I just don't see cell sector as useful, long term, so > > whether it could > > > actually work in some large number of cases is rather immaterial. > > > Since we know that it will fail, regardless of probability > > routing or > > > not, in an unacceptably large number of cases, it seems > > much better to > > > design a system that actually works, particularly given that the > > > technology is available and now standard on most modern > > cell phones. > > > Old cell phone systems won't be running LoST anyway. > > > > > > I have to admit that I find it rather uninteresting whether > > I call the > > > wrong PSAP if I'm 100 ft from the border of the PSAP. > > You'll always > > > have cases where the initial route goes to PSAP A, but the caller > > > moves to PSAP B while talking to the call taker. In the > > town I live, > > > it probably takes about 2 minutes, at 30 mph, to cross the PSAP > > > coverage area. Within that range, I'm also just as likely > > to report on > > > an incident on the other side of the town border. Again, lots of > > > complexity for no operational gain. > > > > > > While it is theoretically possible, with some very low > > probability, to > > > end up exactly on the border between two PSAPs, in that > > case, it just > > > doesn't matter what happens and whether two implementations do the > > > same thing. By definition, either PSAP is as good the other. > > > > > > In those rare cases where the client cares, it can do the > > > probabilistic computation. I'd rather have those that care, pay = the > > > cost, rather than everyone. > > > > > > Henning > > > > > > On Sep 26, 2006, at 9:28 PM, Edge, Stephen wrote: > > > > > > > Hi All > > > > > > > > Thanks for the comments (Martin, Brian, Henning). Though not too > > > > encouraging so far, here are a few responses. > > > > > > > > Martin's comments: I am not proposing including > > > > confidence/probability information in the LoST query (just a > > > > geographic shape would do) although I believe it would help. My > > > > proposal is just to allow optional addition of a confidence = value > > > > associated with a single PSAP URI result in the LoST > > response. That > > > > way the call server knows the likelihood of misrouting > > (e.g. in some > > > > cases could be 50% or higher). If it turns out that the > > chosen PSAP > > > > is not even E911 phase 2 capable, there could be a major > > problem in > > > > rerouting to the correct PSAP because the initially > > chosen PSAP will > > > > not be able to receive a more accurate location estimate. > > However, I > > > > agree that this proposed capability may not be very > > useful initially > > > > because servers may not support it and clients may not be > > adaptable > > > > enough to take advantage. However, that could change in a > > few years > > > > as algorithms get smarter. For example, it would probably > > be quite > > > > simple to perform some of the calculations in non-real time - = e.g. > > > > associate each cell ID with a single PSAP URI and confidence = level > > > > - and > > > > perform a simple lookup in real time. If the capability is not > > > > allowed, then it won't be possible (or at least not so > > > > straightforward) to improve call setup time and routing > > reliability > > > > - which would be a pity. > > > > > > > > Brian's comments: I agree that one input could be a hard edged > > > > polygon in which case (if a uniform probability distribution is > > > > assumed), the resulting confidence is just the > > proportional overlap > > > > with the PSAP coverage area. For some positioning methods (e.g. > > > > yielding other shapes), a probability distribution can be > > assumed in > > > > which case the calculation of the confidence would be > > more complex > > > > (but still possible). The LoST response can remain deterministic > > > > (assuming "perfect > > > > algorithms") as long as the allowed geographic shape inputs are > > > > defined carefully enough (e.g. state any default confidence = level > > > > and/or probability distribution). This is not to say that > > different > > > > algorithms (or possibly even different implementations of > > the same > > > > algorithm) would always yield the same results - in fact, due to > > > > approximations, programming errors and shortcuts etc. > > they probably > > > > would not no matter how simple you make the protocol definition > > > > (e.g. consider a point input exactly on a PSAP boundary). > > > > > > > > Henning's comments: you seem to be saying that cell-sector based > > > > location estimates will typically cause routing errors > > whereas with > > > > more accurate (E911 phase 2 type) location, any routing error > > > > (considering that the terminal will be very close to the > > destination > > > > PSAP's coverage > > > > area) will not be important. I have a somewhat different > > view though > > > > based on similar premises. For a given geographic area location > > > > input L, consider 2 possible results: (a) L is within one PSAP's > > > > coverage area with a confidence level >=3DX (e.g. X =3D 90%); = (b) L > > > > spans >=3D2 PSAP areas with a confidence level > > > (a) occurs with significant frequency when L is cell-sector = based > > > > (which I would find hard to doubt given the large numbers > > of small > > > > urban cells and some large PSAP coverage areas), then using > > > > cell-sector as an initial input could be sensible. For (b), = there > > > > may be value in obtaining more accurate location > > information because > > > > the smaller the size of L, the higher will be the > > incidence of (a). > > > > (b) will still occur sometimes no matter how small L > > becomes (unless > > > > a point), but then the argument that any resulting > > routing error is > > > > less important comes to the rescue and you end up with a > > methodology > > > > that can both reduce call delay and improve routing reliability. > > > > (Note concerning Monte Carlo sampling by the > > > > client: I agree that is one solution but rather inefficient, = also > > > > complex for the client.) > > > > > > > > I look forward to more comments which hopefully can progress = this. > > > > > > > > Kind Regards > > > > > > > > Stephen > > > > -----Original Message----- > > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > > Sent: Tuesday, September 26, 2006 5:26 AM > > > > To: Brian Rosen > > > > Cc: Edge, Stephen; ECRIT > > > > Subject: Re: [Ecrit] Indication of PSAP Confidence Level > > in a LoST > > > > QueryResponse > > > > > > > > I'll also add that earlier discussion has yielded the > > insight that > > > > sector-size areas are pretty useless for call routing, as > > there is a > > > > significant probability of mis-routes. > > > > > > > > This probability won't be reduced all that much by fancy area > > > > maximization techniques or anything else since you simply > > can't tell > > > > which of the PSAP serving areas you're in. With area > > maximization, > > > > for example, users in a cell sector will simply be assigned to > > > > whatever PSAP service area dominates the cell sector. On = average, > > > > across cell towers, that will still make it a 50/50 toss-up. > > > > > > > > For dispatch, mid-sized areas of uncertainty are useful, > > > > corresponding to the typical FCC-compliant uncertainty > > regions of a > > > > few hundred feet. However, worrying that such areas span = multiple > > > > PSAPs and then trying to pick the right one seems rather > > pointless > > > > (sorry...), given the complexity. (If clients really > > care, they can > > > > randomly sample the area, essentially doing a Monte-Carlo > > > > simulation, which will yield an area maximization by design.) > > > > > > > > Thus, I just don't see the benefit. Either the area of > > uncertainty > > > > is too large for routing, as it is for tower/face > > information, or it > > > > is too small to worry about the right PSAP, and can be > > treated as a > > > > point for PSAP selection purposes. > > > > > > > > > > > > Henning > > > > > > > > On Sep 26, 2006, at 7:28 AM, Brian Rosen wrote: > > > > > > > >> I'm not sure I understand what you are proposing. The service > > > >> boundaries are hard edged polygons. If you put a point > > in, you get > > > >> an exact answer out. If you put a shape in, then we could have > > > >> some kind of overlap of the boundary polygons with the > > shape, and > > > >> get uncertainty from that. > > > >> Is that > > > >> what you were proposing? > > > >> > > > >> If so, I think I would support some kind of output that told = you > > > >> how close of a fit we got. If that's not it, perhaps you would > > > >> explain in more detail what you propose. > > > >> > > > >> I do think we are pushing for the LoST resolver to be simple = and > > > >> deterministic. The reason is that it is not in a position to > > > >> understand what the tradeoffs are. In general, the > > closer you get > > > >> to the origin of the location information, the more you > > understand > > > >> what is actually happening on the ground. We want > > earlier elements > > > >> to make the decisions, and not later elements. Thus we > > insist that > > > >> if you have more than one location, the client chooses, > > and not the > > > >> server. If we force the client to interpret inexactness, then = I > > > >> think giving it as much information to make the choice > > as we can is > > > >> a useful thing to do. > > > >> > > > >> Brian > > > >> > > > >>> -----Original Message----- > > > >>> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > > > >>> Sent: Tuesday, September 26, 2006 2:58 AM > > > >>> To: Edge, Stephen; ecrit@ietf.org > > > >>> Subject: RE: [Ecrit] Indication of PSAP Confidence > > Level in a LoST > > > >>> QueryResponse > > > >>> > > > >>> Hi Stephen, > > > >>> > > > >>> I must admit, that I can't see any tangible benefits for this > > > >>> right now - that is probably going to be the biggest > > point leveled > > > >>> against this proposal. > > > >>> > > > >>> These sorts of discussion have been run in the past. > > Consider the > > > >>> discussions on whether or not uncertainty should be included = in > > > >>> LoST (check the archives; it was in the last few weeks). And > > > >>> GEOPRIV have discussed confidence on the past, and aside from > > > >>> problems with people understanding the concepts, the main = point > > > >>> against its inclusion was the lack of perceived benefit. > > > >>> > > > >>> You are probably correct, in that we don't know today > > how we could > > > >>> benefit from things like uncertainty and confidence in > > the future. > > > >>> Certainly, > > > >>> there is wisdom in drawing a line and saying "Ware Ye, Here Be > > > >>> Dragons". > > > >>> Even if you know that there are people living on the > > other side of > > > >>> that line happily, you can get on with your business, which is > > > >>> engineering workable solutions. > > > >>> > > > >>> I suspect that this is primarily because people have > > trouble with > > > >>> the vagaries inherent in mobile and wireless systems. > > For LoST, > > > >>> in the here and now, what you are asking for is a small > > change in > > > >>> the underlying philosophy. This philosophy isn't necessarily > > > >>> written down, but you will find that this WG is currently > > > >>> operating under the assumption that its inputs will be simple. > > > >>> This gives solid, repeatable results; you can write > > algorithms to > > > >>> that; and almost anyone can get it right. > > > >>> Having one > > > >>> result is nice - we don't want request forking, which is a > > > >>> possibility unless you have a clear one-to-one mapping from > > > >>> location to URI... > > > >>> > > > >>> location -> FG -> FG (-> FG ...) -> Tree -> URI > > > >>> > > > >>> You understand the vagaries, and are comfortable with them, = but > > > >>> these scare the willies out of most people - because > > you don't get > > > >>> results in nice tidy boxes. It's also harder to design > > a system > > > >>> that deals with fuzzy inputs. To start with, you need a = really > > > >>> compelling reason to do it. Then, you need to make it > > so easy to > > > >>> do that not doing it would seem recalcitrant. > > > >>> > > > >>> I personally like the idea of building in a little > > tolerance into > > > >>> the whole system. And being able to convey this sort of > > > >>> information could be useful outside of an emergency > > situation as a > > > >>> sort of tuning mechanism. > > > >>> Certainly, it would be useful in combination with location > > > >>> uncertainty and confidence to know whether or not > > current location > > > >>> information is adequate. > > > >>> > > > >>> But this is from the person that reminded GEOPRIV that = location > > > >>> isn't always a simple point in space. > > > >>> > > > >>> Cheers, > > > >>> Martin > > > >>> > > > >>> ________________________________________ > > > >>> From: Edge, Stephen [mailto:sedge@qualcomm.com] > > > >>> Sent: Tuesday, 26 September 2006 2:36 PM > > > >>> To: ecrit@ietf.org > > > >>> Subject: [Ecrit] Indication of PSAP Confidence Level in a LoST > > > >>> Query Response > > > >>> > > > >>> Hi All > > > >>> Here is a topic that may or may not be new but maybe not yet > > > >>> presented in this light. In the not so distant future and > > > >>> certainly within the possible lifetime of the LoST > > capability, it > > > >>> may be possible using new algorithms and additional > > processing and > > > >>> storage availability to determine the probability that a > > > >>> particular PSAP URI is the correct one for a provided > > geographic > > > >>> or civil location (taking account of the fact that any = provided > > > >>> location will often include, implicitly or explicitly, > > some area > > > >>> of uncertainty). This capability is possible in principle even > > > >>> today; it is just that the required amount of processing and > > > >>> storage may be too high (or the ability of currently known > > > >>> algorithms too low) to allow realistic and cost effective > > > >>> implementation. > > > >>> > > > >>> Assuming that a probability value, AKA confidence level, was > > > >>> provided in a LoST response, it would be possible with some > > > >>> solutions being developed (e.g. 3GPP and maybe 3GPP2) > > to obtain a > > > >>> more exact location for a wireless (or maybe wireline) > > user if the > > > >>> confidence value was not high and no significant delay had yet > > > >>> been expended to obtain the initial location. > > > >>> That would then allow a second LoST query with a higher > > > >>> probability of success. It would also permit a network to > > > >>> instigate the initial LoST query using simple location > > information > > > >>> such as cell ID requiring no time to obtain. The overall = result > > > >>> could be significantly lower call delay wherever an initial > > > >>> location mapped unambiguously to a single PSAP URI and more > > > >>> reliable routing for callers in PSAP border areas. > > > >>> > > > >>> This capability may seem strange in a wireline > > environment where a > > > >>> terminal would typically stay put for extended periods of time > > > >>> allowing plenty of opportunity to obtain a location before an > > > >>> emergency call was originated. But in a wireless > > environment, it > > > >>> can be practically impossible to know location with > > anything but > > > >>> very coarse accuracy at any arbitrary point in time and > > the time > > > >>> needed to obtain a location more accurately can be > > significant. It > > > >>> should also be noted that such an enhancement to LoST could be > > > >>> mostly independent of the means used to obtain location > > (whether > > > >>> for the first or second query). In other words, such a > > capability > > > >>> need not (greatly) prejudice issues relating to the > > architecture, > > > >>> procedures and methods used to obtain location. > > > >>> > > > >>> Of course, such an enhancement to LoST might be added > > later after > > > >>> it was well established that algorithms and computational > > > >>> capability would be up to the task. But the addition of > > an extra > > > >>> optional parameter to a LoST response need not impact > > > >>> implementations that choose not to use it (either as a > > client or > > > >>> server). And later implementation support would be > > easier because > > > >>> it would not require any new standards change. (Of course, > > > >>> proprietary support would always be possible, but potentially > > > >>> dangerous because of the risk of LoST evolution in some other > > > >>> direction, such as provision of more than one PSAP URI.) > > > >>> > > > >>> One possible consequence of this proposal might be to = encourage > > > >>> non- uniformity in the algorithms used to convert > > location to PSAP > > > >>> URI - meaning different implementations could > > occasionally deliver > > > >>> different URIs (and different confidence levels) for the same > > > >>> location input and same PSAP database map. But I wonder if = this > > > >>> should really be an issue - e.g. it may well turn out that = some > > > >>> algorithms are better (more reliable, faster etc.) than > > others and > > > >>> that a demonstration of this in a live environment > > would be a good > > > >>> way to ensure that the better ones eventually become > > the ones most > > > >>> widely adopted. > > > >>> > > > >>> Anyhow, please comment on this. > > > >>> Kind Regards > > > >>> Stephen > > > >>> > > ------------------------------------------------------------------ > > > >>> -- > > > > > > >>> - > > > > > > > >>> ----- > > > >>> ---------------------- > > > >>> This message is for the designated recipient only and > > may contain > > > >>> privileged, proprietary, or otherwise private information. > > > >>> If you have received it in error, please notify the sender > > > >>> immediately and delete the original. Any unauthorized > > use of this > > > >>> email is prohibited. > > > >>> > > ------------------------------------------------------------------ > > > >>> -- > > > > > > >>> - > > > > > > > >>> ----- > > > >>> ---------------------- > > > >>> [mf2] > > > >> > > > >> > > > >> _______________________________________________ > > > >> Ecrit mailing list > > > >> Ecrit@ietf.org > > > >> https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 27 20:02:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSjM4-0005Gf-RH; Wed, 27 Sep 2006 20:02:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSjM3-0005Ga-JA for ecrit@ietf.org; Wed, 27 Sep 2006 20:02:19 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSjM2-0000X6-HH for ecrit@ietf.org; Wed, 27 Sep 2006 20:02:19 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Sep 2006 19:02:15 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 27 Sep 2006 19:02:15 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Sep 2006 19:02:14 -0500 Message-ID: From: "Winterbottom, James" To: "Brian Rosen" , "Edge, Stephen" , "Drage, Keith \(Keith\)" , "Henning Schulzrinne" Date: Wed, 27 Sep 2006 19:02:10 -0500 Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a LoSTQueryResponse MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 28 Sep 2006 00:02:14.0848 (UTC) FILETIME=[5AD1EC00:01C6E291] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <002801c6e28f$26a44ba0$640fa8c0@cis.neustar.com> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Indication of PSAP Confidence Level in a LoSTQueryResponse Thread-Index: Acbh16UKFMGg2o6IR+iaxBlT2KdcAwACn8oQABGgsCAAA4iNEAAU0MrQAAC+ziAAAODeMA== X-Spam-Score: 0.0 (/) X-Scan-Signature: bc3b4a0e61e6c2546ab80acca7fc79df Cc: ECRIT , "Thomson, Martin" 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: , Errors-To: ecrit-bounces@ietf.org Brian, TA/NMR and other similar technologies are provide second or subsecond locat= ion determination which provides significant improvements to accuracy over = straight cell. Quite a few PDE and SMLC vendors have products in this space= , and with the changes to J-STD-036 that Stephen mentions XY based routing = deployments are occurring. While I agree that cell-based may be all that is know, it is increasingly n= ot the case, and there is no need to wait for 15 to 20 seconds to get a mor= e accurate fix than cell-based for routing. I speak from experience here as= we have products extensively deployed in this space. Cheers James > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, 28 September 2006 9:46 AM > To: 'Edge, Stephen'; 'Drage, Keith (Keith)'; 'Henning Schulzrinne' > Cc: 'ECRIT'; Thomson, Martin > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a > LoSTQueryResponse >=20 > The PSAPs would prefer to route on accurate data. It can be a significan= t > problem to have the call routed incorrectly because the only information > known at the time the call was placed was cell/sector. >=20 > NENA's position is that, with current technology, cell/sector may be all > the > information there is. It's very clear they don't want to wait the 12-15 > seconds to get accurate location before the call is routed. Therefore, > they > reluctantly accept routing by cell/sector. >=20 > Then you have the issue of, if you are routing by cell/sector, how you do > that. Again, NENA has a pragmatic answer: they decide, in advance, which > PSAP should get the call for a given cell/sector, and they choose a point > within the cell/sector that represents the location of that cell/sector > which will route to the PSAP they want to get the call. What I said abov= e > isn't strictly true in that the chosen point doesn't actually have to be > within the cell/sector; it can be any point. >=20 > I asked them if they would prefer, or would be interested in, representin= g > the cell/sector as a shape, rather than a point. Their answer (again, > this > is North America, and really U.S.) was no, they wanted the representation > to > be a point. The carrier maps cell/sector to a point, and uses the point > to > choose a route. >=20 > Summarizing, the preferred representation for the location of the CALLER > is > a point. The technology forces you to say "point with uncertainty". If > you > cannot, because of limitations in the technology, determine the point at > the > time of the call, it is acceptable, if undesirable, to route based on the > cell/sector. The preferred method for routing based on cell/sector, > according to this NENA group, is to map cell/sector to point, and then us= e > LoST to route based on that point. >=20 > Just as an aside, the PSAPs have a real problem with uncertainty, > primarily > because there is no way to represent the information to a call taker when > different carriers use different uncertainty values. Ask yourself what > you > would like to see on a screen if you get one call with some location and > 70% > uncertainty, and then immediately thereafter, get a call with the same > location and 50% uncertainty, how do you want the screen to show the > difference? While uncertainty is a fact of life in the real world, the > way > we deal with it today is not meeting the need. The net result is that > uncertainty is ignored, not a good answer, but so far, I have not heard > any > proposal for a better answer. If all carriers used the same uncertainty > values, then we might have a way to represent the information. If there > was > an accurate conversion from one uncertainty value to another, that might > be > useful, but I don't think any such thing exists. >=20 > Brian >=20 > > -----Original Message----- > > From: Edge, Stephen [mailto:sedge@qualcomm.com] > > Sent: Wednesday, September 27, 2006 7:29 PM > > To: Drage, Keith (Keith); Brian Rosen; Henning Schulzrinne > > Cc: ECRIT; Thomson, Martin > > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a > > LoSTQueryResponse > > > > Hi Brian, others > > > > It's not clear if NENA are endorsing cell-sector routing or just > > simplifying how it should operate. If the former, I can't help > commenting > > that cell-sector routing did not last very long for circuit mode since, > > soon after initially deployments and under pressure from the PSAPs, so > > called "interim positioning" was added to 3GPP and J-STD-036 spec.s. If > IP > > based emergency call support goes the same way, the issue of performing > > more accurate positioning on a possibly selective basis (and at some > cost > > in extra delay) will surely re-arise. > > > > I also agree with Keith on the worldwide aspect - though up until now, > NA > > seems to have monopolized the most stringent requirements. > > > > Kind Regards > > > > Stephen > > -----Original Message----- > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > Sent: Wednesday, September 27, 2006 9:14 AM > > To: Brian Rosen; Edge, Stephen; Henning Schulzrinne > > Cc: ECRIT; Thomson, Martin > > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a > > LoSTQueryResponse > > > > Some of the terms like "anywhere" are very general. I am unclear whethe= r > > you are giving a response based on NENA knowledge or a wider knowledge. > > > > Remember the scope of ECRIT is to cover worldwide requirements, not jus= t > > NAR. Can you rephrase you answer in terms of the geographical areas > where > > you believe this is the answer, thus therefore identifying those region= s > > where you do not have knowledge of the answer. > > > > Regards > > > > Keith > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: 27 September 2006 12:42 > > > To: 'Edge, Stephen'; 'Henning Schulzrinne' > > > Cc: 'ECRIT'; 'Thomson, Martin' > > > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a > > > LoSTQueryResponse > > > > > > A while ago, we had a discussion of whether there was a need > > > to express cell site and sector as an input format to LoST. > > > I took an action to ask NENA. > > > The "official" answer is not yet available, but unofficially, > > > I can state that there was no support for this idea anywhere. > > > > > > In fact, there was no support for representing cell site and > > > sector by anything except a point, which might be a civic or > > > a geo. The reality is that the PSAPs and the wireless > > > carriers get together and DECIDE which PSAP gets calls from > > > each cell site/sector. Although there are frequent changes > > > in the tower arrangements, it seems there is a choice made > > > who gets the call. Picking a point that lies within the > > > desired PSAP boundary seems to be a very acceptable mechanism. > > > > > > Now, I think this is somewhat na=EFve, based on current > > > experience, and may need to be revisited as technology > > > evolves. However, we asked the question of the experts, and > > > that's what they said they wanted. In this case, we had > > > significant wireless carrier and PSAP participation in the discussion= =2E > > > > > > Although "quick fix" technology is getting better, and more > > > prevalent, and proliferation of location based services means > > > more of the mechanism is "turned on" all the time, most calls > > > emergency calls are still routed by cell site/sector. More > > > accurate information is obtained much later in the call (15 > > > seconds is a typical number). Representing this location as > > > a point is the current answer, and I think that's all we > > > should do now, even though I personally think we will need more. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Edge, Stephen [mailto:sedge@qualcomm.com] > > > > Sent: Wednesday, September 27, 2006 12:38 AM > > > > To: Henning Schulzrinne > > > > Cc: Brian Rosen; Thomson, Martin; ECRIT > > > > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a LoST > > > > QueryResponse > > > > > > > > Hi Henning > > > > > > > > Thanks for the further comments. I appreciate the points > > > you are making. > > > > > > > > For many wireless networks (e.g. 3GPP UMTS, cdma2000), a > > > cell-sector > > > > ID is all the network may generally receive from a terminal > > > inside a > > > > SIP INVITE - since any more accurate location may cost too much in > > > > time (e.g. might not be associated by the network with an emergency > > > > call and hence not assigned priority status). With the 3GPP current > > > > architecture > > > > (3GPP2 has not yet decided one), this will be passed to an > > > E-CSCF in > > > > the serving network and thence to an LRF (Location > > > Retrieval Function) > > > > for use in deriving the PSAP URI. The LRF may be able to instigate > > > > more accurate location (e.g. using a user plane location > > > solution like > > > > SUPL or using the 3GPP control plane solution) but this > > > will take time > > > > and resources. If it turns out that the cell-sector ID maps > > > to a PSAP > > > > URI with high confidence in a majority of cases, there > > > would seem to > > > > be some benefit in performing this mapping rather than adding extra > > > > delay by attempting to obtain a more accurate location. > > > Note that this > > > > is now an issue of call delay just as much as routing reliability > > > > which may be significant so long as legacy PSAPs have to be > > > supported > > > > and there is delay on both the packet and circuit mode > > > sides as well > > > > as in providing the interworking. > > > > > > > > I should also point out that the proposed capability is > > > generally not > > > > possible for circuit mode wireless calls because the control points > > > > for location and routing are separate. Using the same control point > > > > for both functions allows an improvement (in terms of resource > > > > efficiency, call delay and routing reliability) over > > > circuit mode that > > > > could provide a better service. > > > > > > > > I agree that removing unnecessary complexity from the service and > > > > server is worthwhile but I am not sure that an optional capability > > > > that can be omitted initially should count very heavily. > > > For example, > > > > it is possible that algorithms that reliably deliver the > > > most probable > > > > PSAP destination (I mean the truly most probable one and not an > > > > approximation based on centroids or other approximate data) > > > will need > > > > the capability to compute some confidence measure anyway as > > > part of the selection process. > > > > > > > > I suppose one conclusion of this discussion (given the direction in > > > > which it seems headed) would be to leave out this > > > capability initially > > > > and then, based on actual call delay and routing results, > > > reconsider > > > > it or something similar later if needed. > > > > > > > > Kind Regards > > > > > > > > Stephen > > > > -----Original Message----- > > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > > Sent: Tuesday, September 26, 2006 6:52 PM > > > > To: Edge, Stephen > > > > Cc: Brian Rosen; Thomson, Martin; ECRIT > > > > Subject: Re: [Ecrit] Indication of PSAP Confidence Level in a LoST > > > > QueryResponse > > > > > > > > Stephen, > > > > > > > > any engineering is a trade-off between functionality and complexity= =2E > > > > Speaking from some experience, I so far have always regretted when > > > > erring on the side of complexity, on the "it could be > > > useful" theory. > > > > I have no intention of repeating this mistake for LoST, > > > particularly > > > > for a truly mission-critical system. > > > > > > > > You probably would want to review the list discussion as to why I > > > > believe any marginal increase in "correct" routing is just > > > not worth > > > > the tremendous cost in overall system complexity and > > > unpredictability. > > > > I won't bore the rest of the list by repeating these. > > > > > > > > I just don't see cell sector as useful, long term, so > > > whether it could > > > > actually work in some large number of cases is rather immaterial. > > > > Since we know that it will fail, regardless of probability > > > routing or > > > > not, in an unacceptably large number of cases, it seems > > > much better to > > > > design a system that actually works, particularly given that the > > > > technology is available and now standard on most modern > > > cell phones. > > > > Old cell phone systems won't be running LoST anyway. > > > > > > > > I have to admit that I find it rather uninteresting whether > > > I call the > > > > wrong PSAP if I'm 100 ft from the border of the PSAP. > > > You'll always > > > > have cases where the initial route goes to PSAP A, but the caller > > > > moves to PSAP B while talking to the call taker. In the > > > town I live, > > > > it probably takes about 2 minutes, at 30 mph, to cross the PSAP > > > > coverage area. Within that range, I'm also just as likely > > > to report on > > > > an incident on the other side of the town border. Again, lots of > > > > complexity for no operational gain. > > > > > > > > While it is theoretically possible, with some very low > > > probability, to > > > > end up exactly on the border between two PSAPs, in that > > > case, it just > > > > doesn't matter what happens and whether two implementations do the > > > > same thing. By definition, either PSAP is as good the other. > > > > > > > > In those rare cases where the client cares, it can do the > > > > probabilistic computation. I'd rather have those that care, pay the > > > > cost, rather than everyone. > > > > > > > > Henning > > > > > > > > On Sep 26, 2006, at 9:28 PM, Edge, Stephen wrote: > > > > > > > > > Hi All > > > > > > > > > > Thanks for the comments (Martin, Brian, Henning). Though not too > > > > > encouraging so far, here are a few responses. > > > > > > > > > > Martin's comments: I am not proposing including > > > > > confidence/probability information in the LoST query (just a > > > > > geographic shape would do) although I believe it would help. My > > > > > proposal is just to allow optional addition of a confidence value > > > > > associated with a single PSAP URI result in the LoST > > > response. That > > > > > way the call server knows the likelihood of misrouting > > > (e.g. in some > > > > > cases could be 50% or higher). If it turns out that the > > > chosen PSAP > > > > > is not even E911 phase 2 capable, there could be a major > > > problem in > > > > > rerouting to the correct PSAP because the initially > > > chosen PSAP will > > > > > not be able to receive a more accurate location estimate. > > > However, I > > > > > agree that this proposed capability may not be very > > > useful initially > > > > > because servers may not support it and clients may not be > > > adaptable > > > > > enough to take advantage. However, that could change in a > > > few years > > > > > as algorithms get smarter. For example, it would probably > > > be quite > > > > > simple to perform some of the calculations in non-real time - e.g= =2E > > > > > associate each cell ID with a single PSAP URI and confidence leve= l > > > > > - and > > > > > perform a simple lookup in real time. If the capability is not > > > > > allowed, then it won't be possible (or at least not so > > > > > straightforward) to improve call setup time and routing > > > reliability > > > > > - which would be a pity. > > > > > > > > > > Brian's comments: I agree that one input could be a hard edged > > > > > polygon in which case (if a uniform probability distribution is > > > > > assumed), the resulting confidence is just the > > > proportional overlap > > > > > with the PSAP coverage area. For some positioning methods (e.g. > > > > > yielding other shapes), a probability distribution can be > > > assumed in > > > > > which case the calculation of the confidence would be > > > more complex > > > > > (but still possible). The LoST response can remain deterministic > > > > > (assuming "perfect > > > > > algorithms") as long as the allowed geographic shape inputs are > > > > > defined carefully enough (e.g. state any default confidence level > > > > > and/or probability distribution). This is not to say that > > > different > > > > > algorithms (or possibly even different implementations of > > > the same > > > > > algorithm) would always yield the same results - in fact, due to > > > > > approximations, programming errors and shortcuts etc. > > > they probably > > > > > would not no matter how simple you make the protocol definition > > > > > (e.g. consider a point input exactly on a PSAP boundary). > > > > > > > > > > Henning's comments: you seem to be saying that cell-sector based > > > > > location estimates will typically cause routing errors > > > whereas with > > > > > more accurate (E911 phase 2 type) location, any routing error > > > > > (considering that the terminal will be very close to the > > > destination > > > > > PSAP's coverage > > > > > area) will not be important. I have a somewhat different > > > view though > > > > > based on similar premises. For a given geographic area location > > > > > input L, consider 2 possible results: (a) L is within one PSAP's > > > > > coverage area with a confidence level >=3DX (e.g. X =3D 90%); (b)= L > > > > > spans >=3D2 PSAP areas with a confidence level > > > > (a) occurs with significant frequency when L is cell-sector based > > > > > (which I would find hard to doubt given the large numbers > > > of small > > > > > urban cells and some large PSAP coverage areas), then using > > > > > cell-sector as an initial input could be sensible. For (b), there > > > > > may be value in obtaining more accurate location > > > information because > > > > > the smaller the size of L, the higher will be the > > > incidence of (a). > > > > > (b) will still occur sometimes no matter how small L > > > becomes (unless > > > > > a point), but then the argument that any resulting > > > routing error is > > > > > less important comes to the rescue and you end up with a > > > methodology > > > > > that can both reduce call delay and improve routing reliability. > > > > > (Note concerning Monte Carlo sampling by the > > > > > client: I agree that is one solution but rather inefficient, also > > > > > complex for the client.) > > > > > > > > > > I look forward to more comments which hopefully can progress this= =2E > > > > > > > > > > Kind Regards > > > > > > > > > > Stephen > > > > > -----Original Message----- > > > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > > > Sent: Tuesday, September 26, 2006 5:26 AM > > > > > To: Brian Rosen > > > > > Cc: Edge, Stephen; ECRIT > > > > > Subject: Re: [Ecrit] Indication of PSAP Confidence Level > > > in a LoST > > > > > QueryResponse > > > > > > > > > > I'll also add that earlier discussion has yielded the > > > insight that > > > > > sector-size areas are pretty useless for call routing, as > > > there is a > > > > > significant probability of mis-routes. > > > > > > > > > > This probability won't be reduced all that much by fancy area > > > > > maximization techniques or anything else since you simply > > > can't tell > > > > > which of the PSAP serving areas you're in. With area > > > maximization, > > > > > for example, users in a cell sector will simply be assigned to > > > > > whatever PSAP service area dominates the cell sector. On average, > > > > > across cell towers, that will still make it a 50/50 toss-up. > > > > > > > > > > For dispatch, mid-sized areas of uncertainty are useful, > > > > > corresponding to the typical FCC-compliant uncertainty > > > regions of a > > > > > few hundred feet. However, worrying that such areas span multiple > > > > > PSAPs and then trying to pick the right one seems rather > > > pointless > > > > > (sorry...), given the complexity. (If clients really > > > care, they can > > > > > randomly sample the area, essentially doing a Monte-Carlo > > > > > simulation, which will yield an area maximization by design.) > > > > > > > > > > Thus, I just don't see the benefit. Either the area of > > > uncertainty > > > > > is too large for routing, as it is for tower/face > > > information, or it > > > > > is too small to worry about the right PSAP, and can be > > > treated as a > > > > > point for PSAP selection purposes. > > > > > > > > > > > > > > > Henning > > > > > > > > > > On Sep 26, 2006, at 7:28 AM, Brian Rosen wrote: > > > > > > > > > >> I'm not sure I understand what you are proposing. The service > > > > >> boundaries are hard edged polygons. If you put a point > > > in, you get > > > > >> an exact answer out. If you put a shape in, then we could have > > > > >> some kind of overlap of the boundary polygons with the > > > shape, and > > > > >> get uncertainty from that. > > > > >> Is that > > > > >> what you were proposing? > > > > >> > > > > >> If so, I think I would support some kind of output that told you > > > > >> how close of a fit we got. If that's not it, perhaps you would > > > > >> explain in more detail what you propose. > > > > >> > > > > >> I do think we are pushing for the LoST resolver to be simple and > > > > >> deterministic. The reason is that it is not in a position to > > > > >> understand what the tradeoffs are. In general, the > > > closer you get > > > > >> to the origin of the location information, the more you > > > understand > > > > >> what is actually happening on the ground. We want > > > earlier elements > > > > >> to make the decisions, and not later elements. Thus we > > > insist that > > > > >> if you have more than one location, the client chooses, > > > and not the > > > > >> server. If we force the client to interpret inexactness, then I > > > > >> think giving it as much information to make the choice > > > as we can is > > > > >> a useful thing to do. > > > > >> > > > > >> Brian > > > > >> > > > > >>> -----Original Message----- > > > > >>> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > > > > >>> Sent: Tuesday, September 26, 2006 2:58 AM > > > > >>> To: Edge, Stephen; ecrit@ietf.org > > > > >>> Subject: RE: [Ecrit] Indication of PSAP Confidence > > > Level in a LoST > > > > >>> QueryResponse > > > > >>> > > > > >>> Hi Stephen, > > > > >>> > > > > >>> I must admit, that I can't see any tangible benefits for this > > > > >>> right now - that is probably going to be the biggest > > > point leveled > > > > >>> against this proposal. > > > > >>> > > > > >>> These sorts of discussion have been run in the past. > > > Consider the > > > > >>> discussions on whether or not uncertainty should be included in > > > > >>> LoST (check the archives; it was in the last few weeks). And > > > > >>> GEOPRIV have discussed confidence on the past, and aside from > > > > >>> problems with people understanding the concepts, the main point > > > > >>> against its inclusion was the lack of perceived benefit. > > > > >>> > > > > >>> You are probably correct, in that we don't know today > > > how we could > > > > >>> benefit from things like uncertainty and confidence in > > > the future. > > > > >>> Certainly, > > > > >>> there is wisdom in drawing a line and saying "Ware Ye, Here Be > > > > >>> Dragons". > > > > >>> Even if you know that there are people living on the > > > other side of > > > > >>> that line happily, you can get on with your business, which is > > > > >>> engineering workable solutions. > > > > >>> > > > > >>> I suspect that this is primarily because people have > > > trouble with > > > > >>> the vagaries inherent in mobile and wireless systems. > > > For LoST, > > > > >>> in the here and now, what you are asking for is a small > > > change in > > > > >>> the underlying philosophy. This philosophy isn't necessarily > > > > >>> written down, but you will find that this WG is currently > > > > >>> operating under the assumption that its inputs will be simple. > > > > >>> This gives solid, repeatable results; you can write > > > algorithms to > > > > >>> that; and almost anyone can get it right. > > > > >>> Having one > > > > >>> result is nice - we don't want request forking, which is a > > > > >>> possibility unless you have a clear one-to-one mapping from > > > > >>> location to URI... > > > > >>> > > > > >>> location -> FG -> FG (-> FG ...) -> Tree -> URI > > > > >>> > > > > >>> You understand the vagaries, and are comfortable with them, but > > > > >>> these scare the willies out of most people - because > > > you don't get > > > > >>> results in nice tidy boxes. It's also harder to design > > > a system > > > > >>> that deals with fuzzy inputs. To start with, you need a really > > > > >>> compelling reason to do it. Then, you need to make it > > > so easy to > > > > >>> do that not doing it would seem recalcitrant. > > > > >>> > > > > >>> I personally like the idea of building in a little > > > tolerance into > > > > >>> the whole system. And being able to convey this sort of > > > > >>> information could be useful outside of an emergency > > > situation as a > > > > >>> sort of tuning mechanism. > > > > >>> Certainly, it would be useful in combination with location > > > > >>> uncertainty and confidence to know whether or not > > > current location > > > > >>> information is adequate. > > > > >>> > > > > >>> But this is from the person that reminded GEOPRIV that location > > > > >>> isn't always a simple point in space. > > > > >>> > > > > >>> Cheers, > > > > >>> Martin > > > > >>> > > > > >>> ________________________________________ > > > > >>> From: Edge, Stephen [mailto:sedge@qualcomm.com] > > > > >>> Sent: Tuesday, 26 September 2006 2:36 PM > > > > >>> To: ecrit@ietf.org > > > > >>> Subject: [Ecrit] Indication of PSAP Confidence Level in a LoST > > > > >>> Query Response > > > > >>> > > > > >>> Hi All > > > > >>> Here is a topic that may or may not be new but maybe not yet > > > > >>> presented in this light. In the not so distant future and > > > > >>> certainly within the possible lifetime of the LoST > > > capability, it > > > > >>> may be possible using new algorithms and additional > > > processing and > > > > >>> storage availability to determine the probability that a > > > > >>> particular PSAP URI is the correct one for a provided > > > geographic > > > > >>> or civil location (taking account of the fact that any provided > > > > >>> location will often include, implicitly or explicitly, > > > some area > > > > >>> of uncertainty). This capability is possible in principle even > > > > >>> today; it is just that the required amount of processing and > > > > >>> storage may be too high (or the ability of currently known > > > > >>> algorithms too low) to allow realistic and cost effective > > > > >>> implementation. > > > > >>> > > > > >>> Assuming that a probability value, AKA confidence level, was > > > > >>> provided in a LoST response, it would be possible with some > > > > >>> solutions being developed (e.g. 3GPP and maybe 3GPP2) > > > to obtain a > > > > >>> more exact location for a wireless (or maybe wireline) > > > user if the > > > > >>> confidence value was not high and no significant delay had yet > > > > >>> been expended to obtain the initial location. > > > > >>> That would then allow a second LoST query with a higher > > > > >>> probability of success. It would also permit a network to > > > > >>> instigate the initial LoST query using simple location > > > information > > > > >>> such as cell ID requiring no time to obtain. The overall result > > > > >>> could be significantly lower call delay wherever an initial > > > > >>> location mapped unambiguously to a single PSAP URI and more > > > > >>> reliable routing for callers in PSAP border areas. > > > > >>> > > > > >>> This capability may seem strange in a wireline > > > environment where a > > > > >>> terminal would typically stay put for extended periods of time > > > > >>> allowing plenty of opportunity to obtain a location before an > > > > >>> emergency call was originated. But in a wireless > > > environment, it > > > > >>> can be practically impossible to know location with > > > anything but > > > > >>> very coarse accuracy at any arbitrary point in time and > > > the time > > > > >>> needed to obtain a location more accurately can be > > > significant. It > > > > >>> should also be noted that such an enhancement to LoST could be > > > > >>> mostly independent of the means used to obtain location > > > (whether > > > > >>> for the first or second query). In other words, such a > > > capability > > > > >>> need not (greatly) prejudice issues relating to the > > > architecture, > > > > >>> procedures and methods used to obtain location. > > > > >>> > > > > >>> Of course, such an enhancement to LoST might be added > > > later after > > > > >>> it was well established that algorithms and computational > > > > >>> capability would be up to the task. But the addition of > > > an extra > > > > >>> optional parameter to a LoST response need not impact > > > > >>> implementations that choose not to use it (either as a > > > client or > > > > >>> server). And later implementation support would be > > > easier because > > > > >>> it would not require any new standards change. (Of course, > > > > >>> proprietary support would always be possible, but potentially > > > > >>> dangerous because of the risk of LoST evolution in some other > > > > >>> direction, such as provision of more than one PSAP URI.) > > > > >>> > > > > >>> One possible consequence of this proposal might be to encourage > > > > >>> non- uniformity in the algorithms used to convert > > > location to PSAP > > > > >>> URI - meaning different implementations could > > > occasionally deliver > > > > >>> different URIs (and different confidence levels) for the same > > > > >>> location input and same PSAP database map. But I wonder if this > > > > >>> should really be an issue - e.g. it may well turn out that some > > > > >>> algorithms are better (more reliable, faster etc.) than > > > others and > > > > >>> that a demonstration of this in a live environment > > > would be a good > > > > >>> way to ensure that the better ones eventually become > > > the ones most > > > > >>> widely adopted. > > > > >>> > > > > >>> Anyhow, please comment on this. > > > > >>> Kind Regards > > > > >>> Stephen > > > > >>> > > > ------------------------------------------------------------------ > > > > >>> -- > > > > > > > > >>> - > > > > > > > > > >>> ----- > > > > >>> ---------------------- > > > > >>> This message is for the designated recipient only and > > > may contain > > > > >>> privileged, proprietary, or otherwise private information. > > > > >>> If you have received it in error, please notify the sender > > > > >>> immediately and delete the original. Any unauthorized > > > use of this > > > > >>> email is prohibited. > > > > >>> > > > ------------------------------------------------------------------ > > > > >>> -- > > > > > > > > >>> - > > > > > > > > > >>> ----- > > > > >>> ---------------------- > > > > >>> [mf2] > > > > >> > > > > >> > > > > >> _______________________________________________ > > > > >> Ecrit mailing list > > > > >> Ecrit@ietf.org > > > > >> https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 27 20:11:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSjUf-0001yL-Bz; Wed, 27 Sep 2006 20:11:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSjUe-0001yG-Kb for ecrit@ietf.org; Wed, 27 Sep 2006 20:11:12 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSjUd-0001Uq-Eg for ecrit@ietf.org; Wed, 27 Sep 2006 20:11:12 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GSjUH-00073L-8O; Wed, 27 Sep 2006 19:10:50 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Edge, Stephen'" , "'Drage, Keith \(Keith\)'" , "'Henning Schulzrinne'" Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a LoSTQueryResponse Date: Wed, 27 Sep 2006 20:10:54 -0400 Message-ID: <002b01c6e292$92a7f060$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: thread-index: Acbh16UKFMGg2o6IR+iaxBlT2KdcAwACn8oQABGgsCAAA4iNEAAU0MrQAAC+ziAAAODeMAAAZ48g X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: c5360d8dc5896b7620777c236feb980a Cc: 'ECRIT' , "'Thomson, Martin'" 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: , Errors-To: ecrit-bounces@ietf.org James I know that. PSAPs are very pleased with these developments. We all = look forward to the day when no one has to route on cell/sector. This points = out the fact that technology is evolving quickly, and we should expect the requirements for location based services to move with the technology. Brian > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Wednesday, September 27, 2006 8:02 PM > To: Brian Rosen; Edge, Stephen; Drage, Keith (Keith); Henning = Schulzrinne > Cc: ECRIT; Thomson, Martin > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a > LoSTQueryResponse >=20 > Brian, >=20 > TA/NMR and other similar technologies are provide second or subsecond > location determination which provides significant improvements to = accuracy > over straight cell. Quite a few PDE and SMLC vendors have products in = this > space, and with the changes to J-STD-036 that Stephen mentions XY = based > routing deployments are occurring. >=20 > While I agree that cell-based may be all that is know, it is = increasingly > not the case, and there is no need to wait for 15 to 20 seconds to get = a > more accurate fix than cell-based for routing. I speak from experience > here as we have products extensively deployed in this space. >=20 > Cheers > James >=20 >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, 28 September 2006 9:46 AM > > To: 'Edge, Stephen'; 'Drage, Keith (Keith)'; 'Henning Schulzrinne' > > Cc: 'ECRIT'; Thomson, Martin > > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a > > LoSTQueryResponse > > > > The PSAPs would prefer to route on accurate data. It can be a > significant > > problem to have the call routed incorrectly because the only = information > > known at the time the call was placed was cell/sector. > > > > NENA's position is that, with current technology, cell/sector may be = all > > the > > information there is. It's very clear they don't want to wait the = 12-15 > > seconds to get accurate location before the call is routed. = Therefore, > > they > > reluctantly accept routing by cell/sector. > > > > Then you have the issue of, if you are routing by cell/sector, how = you > do > > that. Again, NENA has a pragmatic answer: they decide, in advance, > which > > PSAP should get the call for a given cell/sector, and they choose a > point > > within the cell/sector that represents the location of that = cell/sector > > which will route to the PSAP they want to get the call. What I said > above > > isn't strictly true in that the chosen point doesn't actually have = to be > > within the cell/sector; it can be any point. > > > > I asked them if they would prefer, or would be interested in, > representing > > the cell/sector as a shape, rather than a point. Their answer = (again, > > this > > is North America, and really U.S.) was no, they wanted the > representation > > to > > be a point. The carrier maps cell/sector to a point, and uses the = point > > to > > choose a route. > > > > Summarizing, the preferred representation for the location of the = CALLER > > is > > a point. The technology forces you to say "point with uncertainty". = If > > you > > cannot, because of limitations in the technology, determine the = point at > > the > > time of the call, it is acceptable, if undesirable, to route based = on > the > > cell/sector. The preferred method for routing based on cell/sector, > > according to this NENA group, is to map cell/sector to point, and = then > use > > LoST to route based on that point. > > > > Just as an aside, the PSAPs have a real problem with uncertainty, > > primarily > > because there is no way to represent the information to a call taker > when > > different carriers use different uncertainty values. Ask yourself = what > > you > > would like to see on a screen if you get one call with some location = and > > 70% > > uncertainty, and then immediately thereafter, get a call with the = same > > location and 50% uncertainty, how do you want the screen to show the > > difference? While uncertainty is a fact of life in the real world, = the > > way > > we deal with it today is not meeting the need. The net result is = that > > uncertainty is ignored, not a good answer, but so far, I have not = heard > > any > > proposal for a better answer. If all carriers used the same = uncertainty > > values, then we might have a way to represent the information. If = there > > was > > an accurate conversion from one uncertainty value to another, that = might > > be > > useful, but I don't think any such thing exists. > > > > Brian > > > > > -----Original Message----- > > > From: Edge, Stephen [mailto:sedge@qualcomm.com] > > > Sent: Wednesday, September 27, 2006 7:29 PM > > > To: Drage, Keith (Keith); Brian Rosen; Henning Schulzrinne > > > Cc: ECRIT; Thomson, Martin > > > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a > > > LoSTQueryResponse > > > > > > Hi Brian, others > > > > > > It's not clear if NENA are endorsing cell-sector routing or just > > > simplifying how it should operate. If the former, I can't help > > commenting > > > that cell-sector routing did not last very long for circuit mode > since, > > > soon after initially deployments and under pressure from the = PSAPs, so > > > called "interim positioning" was added to 3GPP and J-STD-036 = spec.s. > If > > IP > > > based emergency call support goes the same way, the issue of > performing > > > more accurate positioning on a possibly selective basis (and at = some > > cost > > > in extra delay) will surely re-arise. > > > > > > I also agree with Keith on the worldwide aspect - though up until = now, > > NA > > > seems to have monopolized the most stringent requirements. > > > > > > Kind Regards > > > > > > Stephen > > > -----Original Message----- > > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > > Sent: Wednesday, September 27, 2006 9:14 AM > > > To: Brian Rosen; Edge, Stephen; Henning Schulzrinne > > > Cc: ECRIT; Thomson, Martin > > > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a > > > LoSTQueryResponse > > > > > > Some of the terms like "anywhere" are very general. I am unclear > whether > > > you are giving a response based on NENA knowledge or a wider > knowledge. > > > > > > Remember the scope of ECRIT is to cover worldwide requirements, = not > just > > > NAR. Can you rephrase you answer in terms of the geographical = areas > > where > > > you believe this is the answer, thus therefore identifying those > regions > > > where you do not have knowledge of the answer. > > > > > > Regards > > > > > > Keith > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: 27 September 2006 12:42 > > > > To: 'Edge, Stephen'; 'Henning Schulzrinne' > > > > Cc: 'ECRIT'; 'Thomson, Martin' > > > > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a > > > > LoSTQueryResponse > > > > > > > > A while ago, we had a discussion of whether there was a need > > > > to express cell site and sector as an input format to LoST. > > > > I took an action to ask NENA. > > > > The "official" answer is not yet available, but unofficially, > > > > I can state that there was no support for this idea anywhere. > > > > > > > > In fact, there was no support for representing cell site and > > > > sector by anything except a point, which might be a civic or > > > > a geo. The reality is that the PSAPs and the wireless > > > > carriers get together and DECIDE which PSAP gets calls from > > > > each cell site/sector. Although there are frequent changes > > > > in the tower arrangements, it seems there is a choice made > > > > who gets the call. Picking a point that lies within the > > > > desired PSAP boundary seems to be a very acceptable mechanism. > > > > > > > > Now, I think this is somewhat na=EFve, based on current > > > > experience, and may need to be revisited as technology > > > > evolves. However, we asked the question of the experts, and > > > > that's what they said they wanted. In this case, we had > > > > significant wireless carrier and PSAP participation in the > discussion. > > > > > > > > Although "quick fix" technology is getting better, and more > > > > prevalent, and proliferation of location based services means > > > > more of the mechanism is "turned on" all the time, most calls > > > > emergency calls are still routed by cell site/sector. More > > > > accurate information is obtained much later in the call (15 > > > > seconds is a typical number). Representing this location as > > > > a point is the current answer, and I think that's all we > > > > should do now, even though I personally think we will need more. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Edge, Stephen [mailto:sedge@qualcomm.com] > > > > > Sent: Wednesday, September 27, 2006 12:38 AM > > > > > To: Henning Schulzrinne > > > > > Cc: Brian Rosen; Thomson, Martin; ECRIT > > > > > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a = LoST > > > > > QueryResponse > > > > > > > > > > Hi Henning > > > > > > > > > > Thanks for the further comments. I appreciate the points > > > > you are making. > > > > > > > > > > For many wireless networks (e.g. 3GPP UMTS, cdma2000), a > > > > cell-sector > > > > > ID is all the network may generally receive from a terminal > > > > inside a > > > > > SIP INVITE - since any more accurate location may cost too = much in > > > > > time (e.g. might not be associated by the network with an > emergency > > > > > call and hence not assigned priority status). With the 3GPP > current > > > > > architecture > > > > > (3GPP2 has not yet decided one), this will be passed to an > > > > E-CSCF in > > > > > the serving network and thence to an LRF (Location > > > > Retrieval Function) > > > > > for use in deriving the PSAP URI. The LRF may be able to = instigate > > > > > more accurate location (e.g. using a user plane location > > > > solution like > > > > > SUPL or using the 3GPP control plane solution) but this > > > > will take time > > > > > and resources. If it turns out that the cell-sector ID maps > > > > to a PSAP > > > > > URI with high confidence in a majority of cases, there > > > > would seem to > > > > > be some benefit in performing this mapping rather than adding > extra > > > > > delay by attempting to obtain a more accurate location. > > > > Note that this > > > > > is now an issue of call delay just as much as routing = reliability > > > > > which may be significant so long as legacy PSAPs have to be > > > > supported > > > > > and there is delay on both the packet and circuit mode > > > > sides as well > > > > > as in providing the interworking. > > > > > > > > > > I should also point out that the proposed capability is > > > > generally not > > > > > possible for circuit mode wireless calls because the control > points > > > > > for location and routing are separate. Using the same control > point > > > > > for both functions allows an improvement (in terms of resource > > > > > efficiency, call delay and routing reliability) over > > > > circuit mode that > > > > > could provide a better service. > > > > > > > > > > I agree that removing unnecessary complexity from the service = and > > > > > server is worthwhile but I am not sure that an optional = capability > > > > > that can be omitted initially should count very heavily. > > > > For example, > > > > > it is possible that algorithms that reliably deliver the > > > > most probable > > > > > PSAP destination (I mean the truly most probable one and not = an > > > > > approximation based on centroids or other approximate data) > > > > will need > > > > > the capability to compute some confidence measure anyway as > > > > part of the selection process. > > > > > > > > > > I suppose one conclusion of this discussion (given the = direction > in > > > > > which it seems headed) would be to leave out this > > > > capability initially > > > > > and then, based on actual call delay and routing results, > > > > reconsider > > > > > it or something similar later if needed. > > > > > > > > > > Kind Regards > > > > > > > > > > Stephen > > > > > -----Original Message----- > > > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > > > Sent: Tuesday, September 26, 2006 6:52 PM > > > > > To: Edge, Stephen > > > > > Cc: Brian Rosen; Thomson, Martin; ECRIT > > > > > Subject: Re: [Ecrit] Indication of PSAP Confidence Level in a = LoST > > > > > QueryResponse > > > > > > > > > > Stephen, > > > > > > > > > > any engineering is a trade-off between functionality and > complexity. > > > > > Speaking from some experience, I so far have always regretted = when > > > > > erring on the side of complexity, on the "it could be > > > > useful" theory. > > > > > I have no intention of repeating this mistake for LoST, > > > > particularly > > > > > for a truly mission-critical system. > > > > > > > > > > You probably would want to review the list discussion as to = why I > > > > > believe any marginal increase in "correct" routing is just > > > > not worth > > > > > the tremendous cost in overall system complexity and > > > > unpredictability. > > > > > I won't bore the rest of the list by repeating these. > > > > > > > > > > I just don't see cell sector as useful, long term, so > > > > whether it could > > > > > actually work in some large number of cases is rather = immaterial. > > > > > Since we know that it will fail, regardless of probability > > > > routing or > > > > > not, in an unacceptably large number of cases, it seems > > > > much better to > > > > > design a system that actually works, particularly given that = the > > > > > technology is available and now standard on most modern > > > > cell phones. > > > > > Old cell phone systems won't be running LoST anyway. > > > > > > > > > > I have to admit that I find it rather uninteresting whether > > > > I call the > > > > > wrong PSAP if I'm 100 ft from the border of the PSAP. > > > > You'll always > > > > > have cases where the initial route goes to PSAP A, but the = caller > > > > > moves to PSAP B while talking to the call taker. In the > > > > town I live, > > > > > it probably takes about 2 minutes, at 30 mph, to cross the = PSAP > > > > > coverage area. Within that range, I'm also just as likely > > > > to report on > > > > > an incident on the other side of the town border. Again, lots = of > > > > > complexity for no operational gain. > > > > > > > > > > While it is theoretically possible, with some very low > > > > probability, to > > > > > end up exactly on the border between two PSAPs, in that > > > > case, it just > > > > > doesn't matter what happens and whether two implementations do = the > > > > > same thing. By definition, either PSAP is as good the other. > > > > > > > > > > In those rare cases where the client cares, it can do the > > > > > probabilistic computation. I'd rather have those that care, = pay > the > > > > > cost, rather than everyone. > > > > > > > > > > Henning > > > > > > > > > > On Sep 26, 2006, at 9:28 PM, Edge, Stephen wrote: > > > > > > > > > > > Hi All > > > > > > > > > > > > Thanks for the comments (Martin, Brian, Henning). Though not = too > > > > > > encouraging so far, here are a few responses. > > > > > > > > > > > > Martin's comments: I am not proposing including > > > > > > confidence/probability information in the LoST query (just a > > > > > > geographic shape would do) although I believe it would help. = My > > > > > > proposal is just to allow optional addition of a confidence > value > > > > > > associated with a single PSAP URI result in the LoST > > > > response. That > > > > > > way the call server knows the likelihood of misrouting > > > > (e.g. in some > > > > > > cases could be 50% or higher). If it turns out that the > > > > chosen PSAP > > > > > > is not even E911 phase 2 capable, there could be a major > > > > problem in > > > > > > rerouting to the correct PSAP because the initially > > > > chosen PSAP will > > > > > > not be able to receive a more accurate location estimate. > > > > However, I > > > > > > agree that this proposed capability may not be very > > > > useful initially > > > > > > because servers may not support it and clients may not be > > > > adaptable > > > > > > enough to take advantage. However, that could change in a > > > > few years > > > > > > as algorithms get smarter. For example, it would probably > > > > be quite > > > > > > simple to perform some of the calculations in non-real time = - > e.g. > > > > > > associate each cell ID with a single PSAP URI and confidence > level > > > > > > - and > > > > > > perform a simple lookup in real time. If the capability is = not > > > > > > allowed, then it won't be possible (or at least not so > > > > > > straightforward) to improve call setup time and routing > > > > reliability > > > > > > - which would be a pity. > > > > > > > > > > > > Brian's comments: I agree that one input could be a hard = edged > > > > > > polygon in which case (if a uniform probability distribution = is > > > > > > assumed), the resulting confidence is just the > > > > proportional overlap > > > > > > with the PSAP coverage area. For some positioning methods = (e.g. > > > > > > yielding other shapes), a probability distribution can be > > > > assumed in > > > > > > which case the calculation of the confidence would be > > > > more complex > > > > > > (but still possible). The LoST response can remain = deterministic > > > > > > (assuming "perfect > > > > > > algorithms") as long as the allowed geographic shape inputs = are > > > > > > defined carefully enough (e.g. state any default confidence > level > > > > > > and/or probability distribution). This is not to say that > > > > different > > > > > > algorithms (or possibly even different implementations of > > > > the same > > > > > > algorithm) would always yield the same results - in fact, = due to > > > > > > approximations, programming errors and shortcuts etc. > > > > they probably > > > > > > would not no matter how simple you make the protocol = definition > > > > > > (e.g. consider a point input exactly on a PSAP boundary). > > > > > > > > > > > > Henning's comments: you seem to be saying that cell-sector = based > > > > > > location estimates will typically cause routing errors > > > > whereas with > > > > > > more accurate (E911 phase 2 type) location, any routing = error > > > > > > (considering that the terminal will be very close to the > > > > destination > > > > > > PSAP's coverage > > > > > > area) will not be important. I have a somewhat different > > > > view though > > > > > > based on similar premises. For a given geographic area = location > > > > > > input L, consider 2 possible results: (a) L is within one = PSAP's > > > > > > coverage area with a confidence level >=3DX (e.g. X =3D = 90%); (b) L > > > > > > spans >=3D2 PSAP areas with a confidence level Assuming > > > > > > (a) occurs with significant frequency when L is cell-sector > based > > > > > > (which I would find hard to doubt given the large numbers > > > > of small > > > > > > urban cells and some large PSAP coverage areas), then using > > > > > > cell-sector as an initial input could be sensible. For (b), > there > > > > > > may be value in obtaining more accurate location > > > > information because > > > > > > the smaller the size of L, the higher will be the > > > > incidence of (a). > > > > > > (b) will still occur sometimes no matter how small L > > > > becomes (unless > > > > > > a point), but then the argument that any resulting > > > > routing error is > > > > > > less important comes to the rescue and you end up with a > > > > methodology > > > > > > that can both reduce call delay and improve routing = reliability. > > > > > > (Note concerning Monte Carlo sampling by the > > > > > > client: I agree that is one solution but rather inefficient, > also > > > > > > complex for the client.) > > > > > > > > > > > > I look forward to more comments which hopefully can progress > this. > > > > > > > > > > > > Kind Regards > > > > > > > > > > > > Stephen > > > > > > -----Original Message----- > > > > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > > > > Sent: Tuesday, September 26, 2006 5:26 AM > > > > > > To: Brian Rosen > > > > > > Cc: Edge, Stephen; ECRIT > > > > > > Subject: Re: [Ecrit] Indication of PSAP Confidence Level > > > > in a LoST > > > > > > QueryResponse > > > > > > > > > > > > I'll also add that earlier discussion has yielded the > > > > insight that > > > > > > sector-size areas are pretty useless for call routing, as > > > > there is a > > > > > > significant probability of mis-routes. > > > > > > > > > > > > This probability won't be reduced all that much by fancy = area > > > > > > maximization techniques or anything else since you simply > > > > can't tell > > > > > > which of the PSAP serving areas you're in. With area > > > > maximization, > > > > > > for example, users in a cell sector will simply be assigned = to > > > > > > whatever PSAP service area dominates the cell sector. On > average, > > > > > > across cell towers, that will still make it a 50/50 toss-up. > > > > > > > > > > > > For dispatch, mid-sized areas of uncertainty are useful, > > > > > > corresponding to the typical FCC-compliant uncertainty > > > > regions of a > > > > > > few hundred feet. However, worrying that such areas span > multiple > > > > > > PSAPs and then trying to pick the right one seems rather > > > > pointless > > > > > > (sorry...), given the complexity. (If clients really > > > > care, they can > > > > > > randomly sample the area, essentially doing a Monte-Carlo > > > > > > simulation, which will yield an area maximization by = design.) > > > > > > > > > > > > Thus, I just don't see the benefit. Either the area of > > > > uncertainty > > > > > > is too large for routing, as it is for tower/face > > > > information, or it > > > > > > is too small to worry about the right PSAP, and can be > > > > treated as a > > > > > > point for PSAP selection purposes. > > > > > > > > > > > > > > > > > > Henning > > > > > > > > > > > > On Sep 26, 2006, at 7:28 AM, Brian Rosen wrote: > > > > > > > > > > > >> I'm not sure I understand what you are proposing. The = service > > > > > >> boundaries are hard edged polygons. If you put a point > > > > in, you get > > > > > >> an exact answer out. If you put a shape in, then we could = have > > > > > >> some kind of overlap of the boundary polygons with the > > > > shape, and > > > > > >> get uncertainty from that. > > > > > >> Is that > > > > > >> what you were proposing? > > > > > >> > > > > > >> If so, I think I would support some kind of output that = told > you > > > > > >> how close of a fit we got. If that's not it, perhaps you = would > > > > > >> explain in more detail what you propose. > > > > > >> > > > > > >> I do think we are pushing for the LoST resolver to be = simple > and > > > > > >> deterministic. The reason is that it is not in a position = to > > > > > >> understand what the tradeoffs are. In general, the > > > > closer you get > > > > > >> to the origin of the location information, the more you > > > > understand > > > > > >> what is actually happening on the ground. We want > > > > earlier elements > > > > > >> to make the decisions, and not later elements. Thus we > > > > insist that > > > > > >> if you have more than one location, the client chooses, > > > > and not the > > > > > >> server. If we force the client to interpret inexactness, = then > I > > > > > >> think giving it as much information to make the choice > > > > as we can is > > > > > >> a useful thing to do. > > > > > >> > > > > > >> Brian > > > > > >> > > > > > >>> -----Original Message----- > > > > > >>> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > > > > > >>> Sent: Tuesday, September 26, 2006 2:58 AM > > > > > >>> To: Edge, Stephen; ecrit@ietf.org > > > > > >>> Subject: RE: [Ecrit] Indication of PSAP Confidence > > > > Level in a LoST > > > > > >>> QueryResponse > > > > > >>> > > > > > >>> Hi Stephen, > > > > > >>> > > > > > >>> I must admit, that I can't see any tangible benefits for = this > > > > > >>> right now - that is probably going to be the biggest > > > > point leveled > > > > > >>> against this proposal. > > > > > >>> > > > > > >>> These sorts of discussion have been run in the past. > > > > Consider the > > > > > >>> discussions on whether or not uncertainty should be = included > in > > > > > >>> LoST (check the archives; it was in the last few weeks). = And > > > > > >>> GEOPRIV have discussed confidence on the past, and aside = from > > > > > >>> problems with people understanding the concepts, the main > point > > > > > >>> against its inclusion was the lack of perceived benefit. > > > > > >>> > > > > > >>> You are probably correct, in that we don't know today > > > > how we could > > > > > >>> benefit from things like uncertainty and confidence in > > > > the future. > > > > > >>> Certainly, > > > > > >>> there is wisdom in drawing a line and saying "Ware Ye, = Here Be > > > > > >>> Dragons". > > > > > >>> Even if you know that there are people living on the > > > > other side of > > > > > >>> that line happily, you can get on with your business, = which is > > > > > >>> engineering workable solutions. > > > > > >>> > > > > > >>> I suspect that this is primarily because people have > > > > trouble with > > > > > >>> the vagaries inherent in mobile and wireless systems. > > > > For LoST, > > > > > >>> in the here and now, what you are asking for is a small > > > > change in > > > > > >>> the underlying philosophy. This philosophy isn't = necessarily > > > > > >>> written down, but you will find that this WG is currently > > > > > >>> operating under the assumption that its inputs will be = simple. > > > > > >>> This gives solid, repeatable results; you can write > > > > algorithms to > > > > > >>> that; and almost anyone can get it right. > > > > > >>> Having one > > > > > >>> result is nice - we don't want request forking, which is a > > > > > >>> possibility unless you have a clear one-to-one mapping = from > > > > > >>> location to URI... > > > > > >>> > > > > > >>> location -> FG -> FG (-> FG ...) -> Tree -> URI > > > > > >>> > > > > > >>> You understand the vagaries, and are comfortable with = them, > but > > > > > >>> these scare the willies out of most people - because > > > > you don't get > > > > > >>> results in nice tidy boxes. It's also harder to design > > > > a system > > > > > >>> that deals with fuzzy inputs. To start with, you need a > really > > > > > >>> compelling reason to do it. Then, you need to make it > > > > so easy to > > > > > >>> do that not doing it would seem recalcitrant. > > > > > >>> > > > > > >>> I personally like the idea of building in a little > > > > tolerance into > > > > > >>> the whole system. And being able to convey this sort of > > > > > >>> information could be useful outside of an emergency > > > > situation as a > > > > > >>> sort of tuning mechanism. > > > > > >>> Certainly, it would be useful in combination with location > > > > > >>> uncertainty and confidence to know whether or not > > > > current location > > > > > >>> information is adequate. > > > > > >>> > > > > > >>> But this is from the person that reminded GEOPRIV that > location > > > > > >>> isn't always a simple point in space. > > > > > >>> > > > > > >>> Cheers, > > > > > >>> Martin > > > > > >>> > > > > > >>> ________________________________________ > > > > > >>> From: Edge, Stephen [mailto:sedge@qualcomm.com] > > > > > >>> Sent: Tuesday, 26 September 2006 2:36 PM > > > > > >>> To: ecrit@ietf.org > > > > > >>> Subject: [Ecrit] Indication of PSAP Confidence Level in a = LoST > > > > > >>> Query Response > > > > > >>> > > > > > >>> Hi All > > > > > >>> Here is a topic that may or may not be new but maybe not = yet > > > > > >>> presented in this light. In the not so distant future and > > > > > >>> certainly within the possible lifetime of the LoST > > > > capability, it > > > > > >>> may be possible using new algorithms and additional > > > > processing and > > > > > >>> storage availability to determine the probability that a > > > > > >>> particular PSAP URI is the correct one for a provided > > > > geographic > > > > > >>> or civil location (taking account of the fact that any > provided > > > > > >>> location will often include, implicitly or explicitly, > > > > some area > > > > > >>> of uncertainty). This capability is possible in principle = even > > > > > >>> today; it is just that the required amount of processing = and > > > > > >>> storage may be too high (or the ability of currently known > > > > > >>> algorithms too low) to allow realistic and cost effective > > > > > >>> implementation. > > > > > >>> > > > > > >>> Assuming that a probability value, AKA confidence level, = was > > > > > >>> provided in a LoST response, it would be possible with = some > > > > > >>> solutions being developed (e.g. 3GPP and maybe 3GPP2) > > > > to obtain a > > > > > >>> more exact location for a wireless (or maybe wireline) > > > > user if the > > > > > >>> confidence value was not high and no significant delay had = yet > > > > > >>> been expended to obtain the initial location. > > > > > >>> That would then allow a second LoST query with a higher > > > > > >>> probability of success. It would also permit a network to > > > > > >>> instigate the initial LoST query using simple location > > > > information > > > > > >>> such as cell ID requiring no time to obtain. The overall > result > > > > > >>> could be significantly lower call delay wherever an = initial > > > > > >>> location mapped unambiguously to a single PSAP URI and = more > > > > > >>> reliable routing for callers in PSAP border areas. > > > > > >>> > > > > > >>> This capability may seem strange in a wireline > > > > environment where a > > > > > >>> terminal would typically stay put for extended periods of = time > > > > > >>> allowing plenty of opportunity to obtain a location before = an > > > > > >>> emergency call was originated. But in a wireless > > > > environment, it > > > > > >>> can be practically impossible to know location with > > > > anything but > > > > > >>> very coarse accuracy at any arbitrary point in time and > > > > the time > > > > > >>> needed to obtain a location more accurately can be > > > > significant. It > > > > > >>> should also be noted that such an enhancement to LoST = could be > > > > > >>> mostly independent of the means used to obtain location > > > > (whether > > > > > >>> for the first or second query). In other words, such a > > > > capability > > > > > >>> need not (greatly) prejudice issues relating to the > > > > architecture, > > > > > >>> procedures and methods used to obtain location. > > > > > >>> > > > > > >>> Of course, such an enhancement to LoST might be added > > > > later after > > > > > >>> it was well established that algorithms and computational > > > > > >>> capability would be up to the task. But the addition of > > > > an extra > > > > > >>> optional parameter to a LoST response need not impact > > > > > >>> implementations that choose not to use it (either as a > > > > client or > > > > > >>> server). And later implementation support would be > > > > easier because > > > > > >>> it would not require any new standards change. (Of course, > > > > > >>> proprietary support would always be possible, but = potentially > > > > > >>> dangerous because of the risk of LoST evolution in some = other > > > > > >>> direction, such as provision of more than one PSAP URI.) > > > > > >>> > > > > > >>> One possible consequence of this proposal might be to > encourage > > > > > >>> non- uniformity in the algorithms used to convert > > > > location to PSAP > > > > > >>> URI - meaning different implementations could > > > > occasionally deliver > > > > > >>> different URIs (and different confidence levels) for the = same > > > > > >>> location input and same PSAP database map. But I wonder if > this > > > > > >>> should really be an issue - e.g. it may well turn out that > some > > > > > >>> algorithms are better (more reliable, faster etc.) than > > > > others and > > > > > >>> that a demonstration of this in a live environment > > > > would be a good > > > > > >>> way to ensure that the better ones eventually become > > > > the ones most > > > > > >>> widely adopted. > > > > > >>> > > > > > >>> Anyhow, please comment on this. > > > > > >>> Kind Regards > > > > > >>> Stephen > > > > > >>> > > > > = ------------------------------------------------------------------ > > > > > >>> -- > > > > > > > > > > >>> - > > > > > > > > > > > >>> ----- > > > > > >>> ---------------------- > > > > > >>> This message is for the designated recipient only and > > > > may contain > > > > > >>> privileged, proprietary, or otherwise private information. > > > > > >>> If you have received it in error, please notify the sender > > > > > >>> immediately and delete the original. Any unauthorized > > > > use of this > > > > > >>> email is prohibited. > > > > > >>> > > > > = ------------------------------------------------------------------ > > > > > >>> -- > > > > > > > > > > >>> - > > > > > > > > > > > >>> ----- > > > > > >>> ---------------------- > > > > > >>> [mf2] > > > > > >> > > > > > >> > > > > > >> _______________________________________________ > > > > > >> Ecrit mailing list > > > > > >> Ecrit@ietf.org > > > > > >> https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit >=20 > = -------------------------------------------------------------------------= - > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > = -------------------------------------------------------------------------= - > ---------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 27 20:13:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSjWo-0002i0-At; Wed, 27 Sep 2006 20:13:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSjWn-0002hm-G6 for ecrit@ietf.org; Wed, 27 Sep 2006 20:13:25 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSjWm-0001zb-Au for ecrit@ietf.org; Wed, 27 Sep 2006 20:13:25 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Sep 2006 19:13:23 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 27 Sep 2006 19:13:22 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Sep 2006 19:13:22 -0500 Message-ID: From: "Winterbottom, James" To: "Brian Rosen" , "Edge, Stephen" , "Drage, Keith \(Keith\)" , "Henning Schulzrinne" Date: Wed, 27 Sep 2006 19:13:18 -0500 Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a LoSTQueryResponse MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 28 Sep 2006 00:13:22.0006 (UTC) FILETIME=[E87A2760:01C6E292] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <002b01c6e292$92a7f060$640fa8c0@cis.neustar.com> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Indication of PSAP Confidence Level in a LoSTQueryResponse Thread-Index: Acbh16UKFMGg2o6IR+iaxBlT2KdcAwACn8oQABGgsCAAA4iNEAAU0MrQAAC+ziAAAODeMAAAZ48gAAArcbA= X-Spam-Score: 0.0 (/) X-Scan-Signature: e2b1c21e3dfd00bd40339b153dfe4f6a Cc: ECRIT , "Thomson, Martin" 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: , Errors-To: ecrit-bounces@ietf.org I guess all I am really trying to say is that I think that Stephen's propos= al has merit. > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, 28 September 2006 10:11 AM > To: Winterbottom, James; 'Edge, Stephen'; 'Drage, Keith (Keith)'; 'Hennin= g > Schulzrinne' > Cc: 'ECRIT'; Thomson, Martin > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a > LoSTQueryResponse >=20 > James >=20 > I know that. PSAPs are very pleased with these developments. We all > look > forward to the day when no one has to route on cell/sector. This points > out > the fact that technology is evolving quickly, and we should expect the > requirements for location based services to move with the technology. >=20 > Brian >=20 > > -----Original Message----- > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: Wednesday, September 27, 2006 8:02 PM > > To: Brian Rosen; Edge, Stephen; Drage, Keith (Keith); Henning > Schulzrinne > > Cc: ECRIT; Thomson, Martin > > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a > > LoSTQueryResponse > > > > Brian, > > > > TA/NMR and other similar technologies are provide second or subsecond > > location determination which provides significant improvements to > accuracy > > over straight cell. Quite a few PDE and SMLC vendors have products in > this > > space, and with the changes to J-STD-036 that Stephen mentions XY based > > routing deployments are occurring. > > > > While I agree that cell-based may be all that is know, it is > increasingly > > not the case, and there is no need to wait for 15 to 20 seconds to get = a > > more accurate fix than cell-based for routing. I speak from experience > > here as we have products extensively deployed in this space. > > > > Cheers > > James > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Thursday, 28 September 2006 9:46 AM > > > To: 'Edge, Stephen'; 'Drage, Keith (Keith)'; 'Henning Schulzrinne' > > > Cc: 'ECRIT'; Thomson, Martin > > > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a > > > LoSTQueryResponse > > > > > > The PSAPs would prefer to route on accurate data. It can be a > > significant > > > problem to have the call routed incorrectly because the only > information > > > known at the time the call was placed was cell/sector. > > > > > > NENA's position is that, with current technology, cell/sector may be > all > > > the > > > information there is. It's very clear they don't want to wait the 12= - > 15 > > > seconds to get accurate location before the call is routed. > Therefore, > > > they > > > reluctantly accept routing by cell/sector. > > > > > > Then you have the issue of, if you are routing by cell/sector, how yo= u > > do > > > that. Again, NENA has a pragmatic answer: they decide, in advance, > > which > > > PSAP should get the call for a given cell/sector, and they choose a > > point > > > within the cell/sector that represents the location of that > cell/sector > > > which will route to the PSAP they want to get the call. What I said > > above > > > isn't strictly true in that the chosen point doesn't actually have to > be > > > within the cell/sector; it can be any point. > > > > > > I asked them if they would prefer, or would be interested in, > > representing > > > the cell/sector as a shape, rather than a point. Their answer (again= , > > > this > > > is North America, and really U.S.) was no, they wanted the > > representation > > > to > > > be a point. The carrier maps cell/sector to a point, and uses the > point > > > to > > > choose a route. > > > > > > Summarizing, the preferred representation for the location of the > CALLER > > > is > > > a point. The technology forces you to say "point with uncertainty". > If > > > you > > > cannot, because of limitations in the technology, determine the point > at > > > the > > > time of the call, it is acceptable, if undesirable, to route based on > > the > > > cell/sector. The preferred method for routing based on cell/sector, > > > according to this NENA group, is to map cell/sector to point, and the= n > > use > > > LoST to route based on that point. > > > > > > Just as an aside, the PSAPs have a real problem with uncertainty, > > > primarily > > > because there is no way to represent the information to a call taker > > when > > > different carriers use different uncertainty values. Ask yourself > what > > > you > > > would like to see on a screen if you get one call with some location > and > > > 70% > > > uncertainty, and then immediately thereafter, get a call with the sam= e > > > location and 50% uncertainty, how do you want the screen to show the > > > difference? While uncertainty is a fact of life in the real world, > the > > > way > > > we deal with it today is not meeting the need. The net result is tha= t > > > uncertainty is ignored, not a good answer, but so far, I have not > heard > > > any > > > proposal for a better answer. If all carriers used the same > uncertainty > > > values, then we might have a way to represent the information. If > there > > > was > > > an accurate conversion from one uncertainty value to another, that > might > > > be > > > useful, but I don't think any such thing exists. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Edge, Stephen [mailto:sedge@qualcomm.com] > > > > Sent: Wednesday, September 27, 2006 7:29 PM > > > > To: Drage, Keith (Keith); Brian Rosen; Henning Schulzrinne > > > > Cc: ECRIT; Thomson, Martin > > > > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a > > > > LoSTQueryResponse > > > > > > > > Hi Brian, others > > > > > > > > It's not clear if NENA are endorsing cell-sector routing or just > > > > simplifying how it should operate. If the former, I can't help > > > commenting > > > > that cell-sector routing did not last very long for circuit mode > > since, > > > > soon after initially deployments and under pressure from the PSAPs, > so > > > > called "interim positioning" was added to 3GPP and J-STD-036 spec.s= =2E > > If > > > IP > > > > based emergency call support goes the same way, the issue of > > performing > > > > more accurate positioning on a possibly selective basis (and at som= e > > > cost > > > > in extra delay) will surely re-arise. > > > > > > > > I also agree with Keith on the worldwide aspect - though up until > now, > > > NA > > > > seems to have monopolized the most stringent requirements. > > > > > > > > Kind Regards > > > > > > > > Stephen > > > > -----Original Message----- > > > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > > > Sent: Wednesday, September 27, 2006 9:14 AM > > > > To: Brian Rosen; Edge, Stephen; Henning Schulzrinne > > > > Cc: ECRIT; Thomson, Martin > > > > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a > > > > LoSTQueryResponse > > > > > > > > Some of the terms like "anywhere" are very general. I am unclear > > whether > > > > you are giving a response based on NENA knowledge or a wider > > knowledge. > > > > > > > > Remember the scope of ECRIT is to cover worldwide requirements, not > > just > > > > NAR. Can you rephrase you answer in terms of the geographical areas > > > where > > > > you believe this is the answer, thus therefore identifying those > > regions > > > > where you do not have knowledge of the answer. > > > > > > > > Regards > > > > > > > > Keith > > > > > > > > > -----Original Message----- > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > Sent: 27 September 2006 12:42 > > > > > To: 'Edge, Stephen'; 'Henning Schulzrinne' > > > > > Cc: 'ECRIT'; 'Thomson, Martin' > > > > > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a > > > > > LoSTQueryResponse > > > > > > > > > > A while ago, we had a discussion of whether there was a need > > > > > to express cell site and sector as an input format to LoST. > > > > > I took an action to ask NENA. > > > > > The "official" answer is not yet available, but unofficially, > > > > > I can state that there was no support for this idea anywhere. > > > > > > > > > > In fact, there was no support for representing cell site and > > > > > sector by anything except a point, which might be a civic or > > > > > a geo. The reality is that the PSAPs and the wireless > > > > > carriers get together and DECIDE which PSAP gets calls from > > > > > each cell site/sector. Although there are frequent changes > > > > > in the tower arrangements, it seems there is a choice made > > > > > who gets the call. Picking a point that lies within the > > > > > desired PSAP boundary seems to be a very acceptable mechanism. > > > > > > > > > > Now, I think this is somewhat na=EFve, based on current > > > > > experience, and may need to be revisited as technology > > > > > evolves. However, we asked the question of the experts, and > > > > > that's what they said they wanted. In this case, we had > > > > > significant wireless carrier and PSAP participation in the > > discussion. > > > > > > > > > > Although "quick fix" technology is getting better, and more > > > > > prevalent, and proliferation of location based services means > > > > > more of the mechanism is "turned on" all the time, most calls > > > > > emergency calls are still routed by cell site/sector. More > > > > > accurate information is obtained much later in the call (15 > > > > > seconds is a typical number). Representing this location as > > > > > a point is the current answer, and I think that's all we > > > > > should do now, even though I personally think we will need more. > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Edge, Stephen [mailto:sedge@qualcomm.com] > > > > > > Sent: Wednesday, September 27, 2006 12:38 AM > > > > > > To: Henning Schulzrinne > > > > > > Cc: Brian Rosen; Thomson, Martin; ECRIT > > > > > > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a > LoST > > > > > > QueryResponse > > > > > > > > > > > > Hi Henning > > > > > > > > > > > > Thanks for the further comments. I appreciate the points > > > > > you are making. > > > > > > > > > > > > For many wireless networks (e.g. 3GPP UMTS, cdma2000), a > > > > > cell-sector > > > > > > ID is all the network may generally receive from a terminal > > > > > inside a > > > > > > SIP INVITE - since any more accurate location may cost too much > in > > > > > > time (e.g. might not be associated by the network with an > > emergency > > > > > > call and hence not assigned priority status). With the 3GPP > > current > > > > > > architecture > > > > > > (3GPP2 has not yet decided one), this will be passed to an > > > > > E-CSCF in > > > > > > the serving network and thence to an LRF (Location > > > > > Retrieval Function) > > > > > > for use in deriving the PSAP URI. The LRF may be able to > instigate > > > > > > more accurate location (e.g. using a user plane location > > > > > solution like > > > > > > SUPL or using the 3GPP control plane solution) but this > > > > > will take time > > > > > > and resources. If it turns out that the cell-sector ID maps > > > > > to a PSAP > > > > > > URI with high confidence in a majority of cases, there > > > > > would seem to > > > > > > be some benefit in performing this mapping rather than adding > > extra > > > > > > delay by attempting to obtain a more accurate location. > > > > > Note that this > > > > > > is now an issue of call delay just as much as routing > reliability > > > > > > which may be significant so long as legacy PSAPs have to be > > > > > supported > > > > > > and there is delay on both the packet and circuit mode > > > > > sides as well > > > > > > as in providing the interworking. > > > > > > > > > > > > I should also point out that the proposed capability is > > > > > generally not > > > > > > possible for circuit mode wireless calls because the control > > points > > > > > > for location and routing are separate. Using the same control > > point > > > > > > for both functions allows an improvement (in terms of resource > > > > > > efficiency, call delay and routing reliability) over > > > > > circuit mode that > > > > > > could provide a better service. > > > > > > > > > > > > I agree that removing unnecessary complexity from the service > and > > > > > > server is worthwhile but I am not sure that an optional > capability > > > > > > that can be omitted initially should count very heavily. > > > > > For example, > > > > > > it is possible that algorithms that reliably deliver the > > > > > most probable > > > > > > PSAP destination (I mean the truly most probable one and not an > > > > > > approximation based on centroids or other approximate data) > > > > > will need > > > > > > the capability to compute some confidence measure anyway as > > > > > part of the selection process. > > > > > > > > > > > > I suppose one conclusion of this discussion (given the directio= n > > in > > > > > > which it seems headed) would be to leave out this > > > > > capability initially > > > > > > and then, based on actual call delay and routing results, > > > > > reconsider > > > > > > it or something similar later if needed. > > > > > > > > > > > > Kind Regards > > > > > > > > > > > > Stephen > > > > > > -----Original Message----- > > > > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > > > > Sent: Tuesday, September 26, 2006 6:52 PM > > > > > > To: Edge, Stephen > > > > > > Cc: Brian Rosen; Thomson, Martin; ECRIT > > > > > > Subject: Re: [Ecrit] Indication of PSAP Confidence Level in a > LoST > > > > > > QueryResponse > > > > > > > > > > > > Stephen, > > > > > > > > > > > > any engineering is a trade-off between functionality and > > complexity. > > > > > > Speaking from some experience, I so far have always regretted > when > > > > > > erring on the side of complexity, on the "it could be > > > > > useful" theory. > > > > > > I have no intention of repeating this mistake for LoST, > > > > > particularly > > > > > > for a truly mission-critical system. > > > > > > > > > > > > You probably would want to review the list discussion as to why > I > > > > > > believe any marginal increase in "correct" routing is just > > > > > not worth > > > > > > the tremendous cost in overall system complexity and > > > > > unpredictability. > > > > > > I won't bore the rest of the list by repeating these. > > > > > > > > > > > > I just don't see cell sector as useful, long term, so > > > > > whether it could > > > > > > actually work in some large number of cases is rather > immaterial. > > > > > > Since we know that it will fail, regardless of probability > > > > > routing or > > > > > > not, in an unacceptably large number of cases, it seems > > > > > much better to > > > > > > design a system that actually works, particularly given that th= e > > > > > > technology is available and now standard on most modern > > > > > cell phones. > > > > > > Old cell phone systems won't be running LoST anyway. > > > > > > > > > > > > I have to admit that I find it rather uninteresting whether > > > > > I call the > > > > > > wrong PSAP if I'm 100 ft from the border of the PSAP. > > > > > You'll always > > > > > > have cases where the initial route goes to PSAP A, but the > caller > > > > > > moves to PSAP B while talking to the call taker. In the > > > > > town I live, > > > > > > it probably takes about 2 minutes, at 30 mph, to cross the PSAP > > > > > > coverage area. Within that range, I'm also just as likely > > > > > to report on > > > > > > an incident on the other side of the town border. Again, lots o= f > > > > > > complexity for no operational gain. > > > > > > > > > > > > While it is theoretically possible, with some very low > > > > > probability, to > > > > > > end up exactly on the border between two PSAPs, in that > > > > > case, it just > > > > > > doesn't matter what happens and whether two implementations do > the > > > > > > same thing. By definition, either PSAP is as good the other. > > > > > > > > > > > > In those rare cases where the client cares, it can do the > > > > > > probabilistic computation. I'd rather have those that care, pay > > the > > > > > > cost, rather than everyone. > > > > > > > > > > > > Henning > > > > > > > > > > > > On Sep 26, 2006, at 9:28 PM, Edge, Stephen wrote: > > > > > > > > > > > > > Hi All > > > > > > > > > > > > > > Thanks for the comments (Martin, Brian, Henning). Though not > too > > > > > > > encouraging so far, here are a few responses. > > > > > > > > > > > > > > Martin's comments: I am not proposing including > > > > > > > confidence/probability information in the LoST query (just a > > > > > > > geographic shape would do) although I believe it would help. > My > > > > > > > proposal is just to allow optional addition of a confidence > > value > > > > > > > associated with a single PSAP URI result in the LoST > > > > > response. That > > > > > > > way the call server knows the likelihood of misrouting > > > > > (e.g. in some > > > > > > > cases could be 50% or higher). If it turns out that the > > > > > chosen PSAP > > > > > > > is not even E911 phase 2 capable, there could be a major > > > > > problem in > > > > > > > rerouting to the correct PSAP because the initially > > > > > chosen PSAP will > > > > > > > not be able to receive a more accurate location estimate. > > > > > However, I > > > > > > > agree that this proposed capability may not be very > > > > > useful initially > > > > > > > because servers may not support it and clients may not be > > > > > adaptable > > > > > > > enough to take advantage. However, that could change in a > > > > > few years > > > > > > > as algorithms get smarter. For example, it would probably > > > > > be quite > > > > > > > simple to perform some of the calculations in non-real time - > > e.g. > > > > > > > associate each cell ID with a single PSAP URI and confidence > > level > > > > > > > - and > > > > > > > perform a simple lookup in real time. If the capability is no= t > > > > > > > allowed, then it won't be possible (or at least not so > > > > > > > straightforward) to improve call setup time and routing > > > > > reliability > > > > > > > - which would be a pity. > > > > > > > > > > > > > > Brian's comments: I agree that one input could be a hard edge= d > > > > > > > polygon in which case (if a uniform probability distribution > is > > > > > > > assumed), the resulting confidence is just the > > > > > proportional overlap > > > > > > > with the PSAP coverage area. For some positioning methods > (e.g. > > > > > > > yielding other shapes), a probability distribution can be > > > > > assumed in > > > > > > > which case the calculation of the confidence would be > > > > > more complex > > > > > > > (but still possible). The LoST response can remain > deterministic > > > > > > > (assuming "perfect > > > > > > > algorithms") as long as the allowed geographic shape inputs > are > > > > > > > defined carefully enough (e.g. state any default confidence > > level > > > > > > > and/or probability distribution). This is not to say that > > > > > different > > > > > > > algorithms (or possibly even different implementations of > > > > > the same > > > > > > > algorithm) would always yield the same results - in fact, due > to > > > > > > > approximations, programming errors and shortcuts etc. > > > > > they probably > > > > > > > would not no matter how simple you make the protocol > definition > > > > > > > (e.g. consider a point input exactly on a PSAP boundary). > > > > > > > > > > > > > > Henning's comments: you seem to be saying that cell-sector > based > > > > > > > location estimates will typically cause routing errors > > > > > whereas with > > > > > > > more accurate (E911 phase 2 type) location, any routing error > > > > > > > (considering that the terminal will be very close to the > > > > > destination > > > > > > > PSAP's coverage > > > > > > > area) will not be important. I have a somewhat different > > > > > view though > > > > > > > based on similar premises. For a given geographic area > location > > > > > > > input L, consider 2 possible results: (a) L is within one > PSAP's > > > > > > > coverage area with a confidence level >=3DX (e.g. X =3D 90%);= (b) > L > > > > > > > spans >=3D2 PSAP areas with a confidence level > Assuming > > > > > > > (a) occurs with significant frequency when L is cell-sector > > based > > > > > > > (which I would find hard to doubt given the large numbers > > > > > of small > > > > > > > urban cells and some large PSAP coverage areas), then using > > > > > > > cell-sector as an initial input could be sensible. For (b), > > there > > > > > > > may be value in obtaining more accurate location > > > > > information because > > > > > > > the smaller the size of L, the higher will be the > > > > > incidence of (a). > > > > > > > (b) will still occur sometimes no matter how small L > > > > > becomes (unless > > > > > > > a point), but then the argument that any resulting > > > > > routing error is > > > > > > > less important comes to the rescue and you end up with a > > > > > methodology > > > > > > > that can both reduce call delay and improve routing > reliability. > > > > > > > (Note concerning Monte Carlo sampling by the > > > > > > > client: I agree that is one solution but rather inefficient, > > also > > > > > > > complex for the client.) > > > > > > > > > > > > > > I look forward to more comments which hopefully can progress > > this. > > > > > > > > > > > > > > Kind Regards > > > > > > > > > > > > > > Stephen > > > > > > > -----Original Message----- > > > > > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > > > > > Sent: Tuesday, September 26, 2006 5:26 AM > > > > > > > To: Brian Rosen > > > > > > > Cc: Edge, Stephen; ECRIT > > > > > > > Subject: Re: [Ecrit] Indication of PSAP Confidence Level > > > > > in a LoST > > > > > > > QueryResponse > > > > > > > > > > > > > > I'll also add that earlier discussion has yielded the > > > > > insight that > > > > > > > sector-size areas are pretty useless for call routing, as > > > > > there is a > > > > > > > significant probability of mis-routes. > > > > > > > > > > > > > > This probability won't be reduced all that much by fancy area > > > > > > > maximization techniques or anything else since you simply > > > > > can't tell > > > > > > > which of the PSAP serving areas you're in. With area > > > > > maximization, > > > > > > > for example, users in a cell sector will simply be assigned t= o > > > > > > > whatever PSAP service area dominates the cell sector. On > > average, > > > > > > > across cell towers, that will still make it a 50/50 toss-up. > > > > > > > > > > > > > > For dispatch, mid-sized areas of uncertainty are useful, > > > > > > > corresponding to the typical FCC-compliant uncertainty > > > > > regions of a > > > > > > > few hundred feet. However, worrying that such areas span > > multiple > > > > > > > PSAPs and then trying to pick the right one seems rather > > > > > pointless > > > > > > > (sorry...), given the complexity. (If clients really > > > > > care, they can > > > > > > > randomly sample the area, essentially doing a Monte-Carlo > > > > > > > simulation, which will yield an area maximization by design.) > > > > > > > > > > > > > > Thus, I just don't see the benefit. Either the area of > > > > > uncertainty > > > > > > > is too large for routing, as it is for tower/face > > > > > information, or it > > > > > > > is too small to worry about the right PSAP, and can be > > > > > treated as a > > > > > > > point for PSAP selection purposes. > > > > > > > > > > > > > > > > > > > > > Henning > > > > > > > > > > > > > > On Sep 26, 2006, at 7:28 AM, Brian Rosen wrote: > > > > > > > > > > > > > >> I'm not sure I understand what you are proposing. The > service > > > > > > >> boundaries are hard edged polygons. If you put a point > > > > > in, you get > > > > > > >> an exact answer out. If you put a shape in, then we could > have > > > > > > >> some kind of overlap of the boundary polygons with the > > > > > shape, and > > > > > > >> get uncertainty from that. > > > > > > >> Is that > > > > > > >> what you were proposing? > > > > > > >> > > > > > > >> If so, I think I would support some kind of output that told > > you > > > > > > >> how close of a fit we got. If that's not it, perhaps you > would > > > > > > >> explain in more detail what you propose. > > > > > > >> > > > > > > >> I do think we are pushing for the LoST resolver to be simple > > and > > > > > > >> deterministic. The reason is that it is not in a position t= o > > > > > > >> understand what the tradeoffs are. In general, the > > > > > closer you get > > > > > > >> to the origin of the location information, the more you > > > > > understand > > > > > > >> what is actually happening on the ground. We want > > > > > earlier elements > > > > > > >> to make the decisions, and not later elements. Thus we > > > > > insist that > > > > > > >> if you have more than one location, the client chooses, > > > > > and not the > > > > > > >> server. If we force the client to interpret inexactness, > then > > I > > > > > > >> think giving it as much information to make the choice > > > > > as we can is > > > > > > >> a useful thing to do. > > > > > > >> > > > > > > >> Brian > > > > > > >> > > > > > > >>> -----Original Message----- > > > > > > >>> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > > > > > > >>> Sent: Tuesday, September 26, 2006 2:58 AM > > > > > > >>> To: Edge, Stephen; ecrit@ietf.org > > > > > > >>> Subject: RE: [Ecrit] Indication of PSAP Confidence > > > > > Level in a LoST > > > > > > >>> QueryResponse > > > > > > >>> > > > > > > >>> Hi Stephen, > > > > > > >>> > > > > > > >>> I must admit, that I can't see any tangible benefits for > this > > > > > > >>> right now - that is probably going to be the biggest > > > > > point leveled > > > > > > >>> against this proposal. > > > > > > >>> > > > > > > >>> These sorts of discussion have been run in the past. > > > > > Consider the > > > > > > >>> discussions on whether or not uncertainty should be include= d > > in > > > > > > >>> LoST (check the archives; it was in the last few weeks). > And > > > > > > >>> GEOPRIV have discussed confidence on the past, and aside > from > > > > > > >>> problems with people understanding the concepts, the main > > point > > > > > > >>> against its inclusion was the lack of perceived benefit. > > > > > > >>> > > > > > > >>> You are probably correct, in that we don't know today > > > > > how we could > > > > > > >>> benefit from things like uncertainty and confidence in > > > > > the future. > > > > > > >>> Certainly, > > > > > > >>> there is wisdom in drawing a line and saying "Ware Ye, Here > Be > > > > > > >>> Dragons". > > > > > > >>> Even if you know that there are people living on the > > > > > other side of > > > > > > >>> that line happily, you can get on with your business, which > is > > > > > > >>> engineering workable solutions. > > > > > > >>> > > > > > > >>> I suspect that this is primarily because people have > > > > > trouble with > > > > > > >>> the vagaries inherent in mobile and wireless systems. > > > > > For LoST, > > > > > > >>> in the here and now, what you are asking for is a small > > > > > change in > > > > > > >>> the underlying philosophy. This philosophy isn't > necessarily > > > > > > >>> written down, but you will find that this WG is currently > > > > > > >>> operating under the assumption that its inputs will be > simple. > > > > > > >>> This gives solid, repeatable results; you can write > > > > > algorithms to > > > > > > >>> that; and almost anyone can get it right. > > > > > > >>> Having one > > > > > > >>> result is nice - we don't want request forking, which is a > > > > > > >>> possibility unless you have a clear one-to-one mapping from > > > > > > >>> location to URI... > > > > > > >>> > > > > > > >>> location -> FG -> FG (-> FG ...) -> Tree -> URI > > > > > > >>> > > > > > > >>> You understand the vagaries, and are comfortable with them, > > but > > > > > > >>> these scare the willies out of most people - because > > > > > you don't get > > > > > > >>> results in nice tidy boxes. It's also harder to design > > > > > a system > > > > > > >>> that deals with fuzzy inputs. To start with, you need a > > really > > > > > > >>> compelling reason to do it. Then, you need to make it > > > > > so easy to > > > > > > >>> do that not doing it would seem recalcitrant. > > > > > > >>> > > > > > > >>> I personally like the idea of building in a little > > > > > tolerance into > > > > > > >>> the whole system. And being able to convey this sort of > > > > > > >>> information could be useful outside of an emergency > > > > > situation as a > > > > > > >>> sort of tuning mechanism. > > > > > > >>> Certainly, it would be useful in combination with location > > > > > > >>> uncertainty and confidence to know whether or not > > > > > current location > > > > > > >>> information is adequate. > > > > > > >>> > > > > > > >>> But this is from the person that reminded GEOPRIV that > > location > > > > > > >>> isn't always a simple point in space. > > > > > > >>> > > > > > > >>> Cheers, > > > > > > >>> Martin > > > > > > >>> > > > > > > >>> ________________________________________ > > > > > > >>> From: Edge, Stephen [mailto:sedge@qualcomm.com] > > > > > > >>> Sent: Tuesday, 26 September 2006 2:36 PM > > > > > > >>> To: ecrit@ietf.org > > > > > > >>> Subject: [Ecrit] Indication of PSAP Confidence Level in a > LoST > > > > > > >>> Query Response > > > > > > >>> > > > > > > >>> Hi All > > > > > > >>> Here is a topic that may or may not be new but maybe not ye= t > > > > > > >>> presented in this light. In the not so distant future and > > > > > > >>> certainly within the possible lifetime of the LoST > > > > > capability, it > > > > > > >>> may be possible using new algorithms and additional > > > > > processing and > > > > > > >>> storage availability to determine the probability that a > > > > > > >>> particular PSAP URI is the correct one for a provided > > > > > geographic > > > > > > >>> or civil location (taking account of the fact that any > > provided > > > > > > >>> location will often include, implicitly or explicitly, > > > > > some area > > > > > > >>> of uncertainty). This capability is possible in principle > even > > > > > > >>> today; it is just that the required amount of processing an= d > > > > > > >>> storage may be too high (or the ability of currently known > > > > > > >>> algorithms too low) to allow realistic and cost effective > > > > > > >>> implementation. > > > > > > >>> > > > > > > >>> Assuming that a probability value, AKA confidence level, wa= s > > > > > > >>> provided in a LoST response, it would be possible with some > > > > > > >>> solutions being developed (e.g. 3GPP and maybe 3GPP2) > > > > > to obtain a > > > > > > >>> more exact location for a wireless (or maybe wireline) > > > > > user if the > > > > > > >>> confidence value was not high and no significant delay had > yet > > > > > > >>> been expended to obtain the initial location. > > > > > > >>> That would then allow a second LoST query with a higher > > > > > > >>> probability of success. It would also permit a network to > > > > > > >>> instigate the initial LoST query using simple location > > > > > information > > > > > > >>> such as cell ID requiring no time to obtain. The overall > > result > > > > > > >>> could be significantly lower call delay wherever an initial > > > > > > >>> location mapped unambiguously to a single PSAP URI and more > > > > > > >>> reliable routing for callers in PSAP border areas. > > > > > > >>> > > > > > > >>> This capability may seem strange in a wireline > > > > > environment where a > > > > > > >>> terminal would typically stay put for extended periods of > time > > > > > > >>> allowing plenty of opportunity to obtain a location before > an > > > > > > >>> emergency call was originated. But in a wireless > > > > > environment, it > > > > > > >>> can be practically impossible to know location with > > > > > anything but > > > > > > >>> very coarse accuracy at any arbitrary point in time and > > > > > the time > > > > > > >>> needed to obtain a location more accurately can be > > > > > significant. It > > > > > > >>> should also be noted that such an enhancement to LoST could > be > > > > > > >>> mostly independent of the means used to obtain location > > > > > (whether > > > > > > >>> for the first or second query). In other words, such a > > > > > capability > > > > > > >>> need not (greatly) prejudice issues relating to the > > > > > architecture, > > > > > > >>> procedures and methods used to obtain location. > > > > > > >>> > > > > > > >>> Of course, such an enhancement to LoST might be added > > > > > later after > > > > > > >>> it was well established that algorithms and computational > > > > > > >>> capability would be up to the task. But the addition of > > > > > an extra > > > > > > >>> optional parameter to a LoST response need not impact > > > > > > >>> implementations that choose not to use it (either as a > > > > > client or > > > > > > >>> server). And later implementation support would be > > > > > easier because > > > > > > >>> it would not require any new standards change. (Of course, > > > > > > >>> proprietary support would always be possible, but > potentially > > > > > > >>> dangerous because of the risk of LoST evolution in some > other > > > > > > >>> direction, such as provision of more than one PSAP URI.) > > > > > > >>> > > > > > > >>> One possible consequence of this proposal might be to > > encourage > > > > > > >>> non- uniformity in the algorithms used to convert > > > > > location to PSAP > > > > > > >>> URI - meaning different implementations could > > > > > occasionally deliver > > > > > > >>> different URIs (and different confidence levels) for the > same > > > > > > >>> location input and same PSAP database map. But I wonder if > > this > > > > > > >>> should really be an issue - e.g. it may well turn out that > > some > > > > > > >>> algorithms are better (more reliable, faster etc.) than > > > > > others and > > > > > > >>> that a demonstration of this in a live environment > > > > > would be a good > > > > > > >>> way to ensure that the better ones eventually become > > > > > the ones most > > > > > > >>> widely adopted. > > > > > > >>> > > > > > > >>> Anyhow, please comment on this. > > > > > > >>> Kind Regards > > > > > > >>> Stephen > > > > > > >>> > > > > > -----------------------------------------------------------------= - > > > > > > >>> -- > > > > > > > > > > > > >>> - > > > > > > > > > > > > > >>> ----- > > > > > > >>> ---------------------- > > > > > > >>> This message is for the designated recipient only and > > > > > may contain > > > > > > >>> privileged, proprietary, or otherwise private information. > > > > > > >>> If you have received it in error, please notify the sender > > > > > > >>> immediately and delete the original. Any unauthorized > > > > > use of this > > > > > > >>> email is prohibited. > > > > > > >>> > > > > > -----------------------------------------------------------------= - > > > > > > >>> -- > > > > > > > > > > > > >>> - > > > > > > > > > > > > > >>> ----- > > > > > > >>> ---------------------- > > > > > > >>> [mf2] > > > > > > >> > > > > > > >> > > > > > > >> _______________________________________________ > > > > > > >> Ecrit mailing list > > > > > > >> Ecrit@ietf.org > > > > > > >> https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Ecrit mailing list > > > > > Ecrit@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > -----------------------------------------------------------------------= - > -- > > ---------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > -----------------------------------------------------------------------= - > -- > > ---------------------- > > [mf2] >=20 ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 27 20:33:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSjqC-0004MZ-UD; Wed, 27 Sep 2006 20:33:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSjpD-0004DS-Un for ecrit@ietf.org; Wed, 27 Sep 2006 20:32:27 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSjc0-0002tA-6Y for ecrit@ietf.org; Wed, 27 Sep 2006 20:18:51 -0400 Received: from lion.cs.columbia.edu (IDENT:U38wIRCAee2qG6rOuO3ggvepdMLBBVxf@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k8S0Ij5Q004239 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 27 Sep 2006 20:18:45 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k8S0Ijg7000927 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 27 Sep 2006 20:18:45 -0400 Message-ID: <451B14E0.9070300@cs.columbia.edu> Date: Wed, 27 Sep 2006 20:18:40 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] Indication of PSAP Confidence Level in a LoSTQueryResponse References: <002801c6e28f$26a44ba0$640fa8c0@cis.neustar.com> In-Reply-To: <002801c6e28f$26a44ba0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter2.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'll also re-iterate that average uncertainty is likely to be more misleading than helpful since there's likely to be bias for particular regions and points. In other words, a particular area may be particularly noisy (say, because of low signal levels), so that simply drawing the standard technology performance radius may well confuse more than help. > > Just as an aside, the PSAPs have a real problem with uncertainty, primarily > because there is no way to represent the information to a call taker when > different carriers use different uncertainty values. Ask yourself what you > would like to see on a screen if you get one call with some location and 70% > uncertainty, and then immediately thereafter, get a call with the same > location and 50% uncertainty, how do you want the screen to show the > difference? While uncertainty is a fact of life in the real world, the way > we deal with it today is not meeting the need. The net result is that > uncertainty is ignored, not a good answer, but so far, I have not heard any > proposal for a better answer. If all carriers used the same uncertainty > values, then we might have a way to represent the information. If there was > an accurate conversion from one uncertainty value to another, that might be > useful, but I don't think any such thing exists. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 27 21:16:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSkVK-0005oT-MA; Wed, 27 Sep 2006 21:15:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSkVJ-0005nd-I6 for ecrit@ietf.org; Wed, 27 Sep 2006 21:15:57 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSkVI-0001Fp-B8 for ecrit@ietf.org; Wed, 27 Sep 2006 21:15:57 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Sep 2006 20:15:55 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 27 Sep 2006 20:15:54 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Sep 2006 20:15:54 -0500 Message-ID: From: "Thomson, Martin" To: "Henning Schulzrinne" , "Brian Rosen" Date: Wed, 27 Sep 2006 20:15:52 -0500 Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a LoSTQueryResponse MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 28 Sep 2006 01:15:54.0516 (UTC) FILETIME=[A525BD40:01C6E29B] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <451B14E0.9070300@cs.columbia.edu> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Indication of PSAP Confidence Level in a LoSTQueryResponse Thread-Index: AcbildWpIgjN8VccQziAddWTOkdXqgABJCNQ X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0844437120==" Errors-To: ecrit-bounces@ietf.org --===============0844437120== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message SSBzZWUgdGhhdCB0aGlzIGVudGlyZSBkaXNjdXNzaW9uIGlzIGZyYXVnaHQgd2l0aCBhc3N1bXB0 aW9ucywgc29tZSBvZiB0aGVtIG1pc2xlYWRpbmcuDQoNClRoZSByZWFsaXR5IG9mIGNlbGwvc2Vj dG9yLCBldmVuIGlmIGl0IGRvZXMgZ28gYXdheSwgaXMgbm90IHNvbWV0aGluZyB3ZSBzaG91bGQg YmUgY29uY2VybmVkIGFib3V0LiAgV2UgZG8gbm90IHdhbnQsIG5vciBkbyB3ZSBuZWVkLCB0byBj b25zaWRlciBwcmltaXRpdmVzIGZyb20gdGhlIG5ldHdvcmsgYmVhcmVyIGluIG91ciBoaWdoZXIg bGF5ZXIgcHJvdG9jb2xzLiAgTG9TVCBzaG91bGQgZGVhbCBvbmx5IHdpdGggbG9jYXRpb24gYXMg aW5wdXQuDQoNCkN1cnJlbnRseSwgdGhlcmUgaXMgYW4gb3B0aW1pemF0aW9uIHN0ZXAgdGhhdCBv Y2N1cnMgd2hlcmUgcm91dGluZyBmdW5jdGlvbnMsIHdoaWNoIGFyZSBjby1ob3N0ZWQgd2l0aCBk ZXRlcm1pbmF0aW9uIGZ1bmN0aW9ucywgZGV0ZXJtaW5lIGEgcm91dGUgYmFzZWQgb24gdGhlc2Ug bmV0d29yayBiZWFyZXIgcHJpbWl0aXZlcyAoU0FJIGlzIHRoZSBtb3N0IHdpZGVseSB1c2VkIGNh c2UpLiAgIFRoaXMgc2hvdWxkIG5vdCBiZSByZWxldmFudCB0byBvdXIgZGlzY3Vzc2lvbiBiZWNh dXNlIHdlIGhhdmUgYWxyZWFkeSBkcmF3biB0aGUgbGluZSBiZXR3ZWVuIHRoZSBkZXRlcm1pbmF0 aW9uIGZ1bmN0aW9uIGFuZCB0aGUgcm91dGluZyBmdW5jdGlvbi4NCg0KSnVzdCBiZWNhdXNlIHdl IGRlY2lkZSBub3QgdG8gYWNjZXB0IGJlYXJlciBwcmltaXRpdmVzLCBkb2Vzbid0IG1lYW4gdGhh dCB3ZSBzaG91bGQgaWdub3JlIHRoZSByZWFsaXRpZXMgb2YgdGhlIHNpdHVhdGlvbiB3aGVuIGNv bnNpZGVyaW5nIHRoZSBmb3JtIG9mIGxvY2F0aW9uIHRoYXQgd2UgaGFuZGxlLiAgVGhlIHJlYWxp dHkgaXMgdGhhdCBsb2NhdGlvbiBpcyBzdWJqZWN0IHRvIHVuY2VydGFpbnR5LCBhbmQgaW4gbW9i aWxlIGNhc2VzIGluIHBhcnRpY3VsYXIsIHRoYXQgdW5jZXJ0YWludHkgaXMgbW9yZSB0aGFuIHdl IG1pZ2h0IG90aGVyd2lzZSBsaWtlLiAgWWVzLCBtaXNyb3V0aW5nIHdpbGwgb2NjdXIsIGJ1dCBv YnZpb3VzbHkgd2UgbmVlZCB0byB0YWtlIHdoYXQgc3RlcHMgd2UgY2FuIHRvIGFkZHJlc3MgdGhh dC4gIEZvciB0aGUgZGV0ZXJtaW5hdGlvbiBzaWRlLCB0aGlzIGlzIG9idmlvdXNseSBhYm91dCBp bXByb3ZpbmcgbG9jYXRpb24gcHJlY2lzaW9uOyBmb3IgdGhlIHJvdXRpbmcgc2lkZSwgd2Ugb2J2 aW91c2x5IGhhdmUgYSBsaXR0bGUgd2F5IHRvIGdvIHlldC4NCg0KQ2hlZXJzLA0KTWFydGluDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBm b3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxl Z2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uICANCklm IHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIN CmltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1 c2Ugb2YNCnRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KW21mMl0= --===============0844437120== 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 --===============0844437120==-- From ecrit-bounces@ietf.org Thu Sep 28 09:04:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSvYr-0004H9-2y; Thu, 28 Sep 2006 09:04:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSvYp-0004H4-Np for ecrit@ietf.org; Thu, 28 Sep 2006 09:04:19 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSvYo-0003We-Da for ecrit@ietf.org; Thu, 28 Sep 2006 09:04:19 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GSvYd-0003WA-QM; Thu, 28 Sep 2006 08:04:08 -0500 From: "Brian Rosen" To: "'Thomson, Martin'" , "'Henning Schulzrinne'" Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a LoSTQueryResponse Date: Thu, 28 Sep 2006 09:04:08 -0400 Message-ID: <00c801c6e2fe$97beeb00$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: thread-index: AcbildWpIgjN8VccQziAddWTOkdXqgABJCNQABi1EoA= X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Martin I don't understand what this message is telling me. I think there is no discussion on what is input, beyond the one issue I was working on, which was whether there should be a representation of cell/sector beyond what we now have. The answer to that question, from NENA's point of view, is no. I think we all agree we have separated determination from routing. I have no idea what SAI is, but I suspect it's irrelevant to the present discussion. I don't know what a "bearer primitive" is, and I don't know if it has any relevance to the present discussion. I understand, in an engineering sense, what uncertainty represents. I accept that it represents "reality". I am beginning to have a whole lot more sympathy with the PSAP folks who are very frustrated with the engineers and their uncertainty, mostly because no one can tell them what the heck they can do with it. What is it that anyone can do with uncertainty? At the moment, I have heard nothing beyond ignore it. I understand that it's real. I have some vague notion that we should be able to use it intelligently. I have no idea what that is. So, while I'm okay with carrying it around, in the hope that some day we can use it, I'd rather not get into a lot of detail unless someone can say what the heck we DO with it. Right now, it's some number you can hide behind when the caller isn't where he is reported to be ignoring uncertainty. That's a useful thing in a legal sense, but doesn't really help anyone. Brian > -----Original Message----- > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > Sent: Wednesday, September 27, 2006 9:16 PM > To: Henning Schulzrinne; Brian Rosen > Cc: ECRIT > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a > LoSTQueryResponse > > I see that this entire discussion is fraught with assumptions, some of > them misleading. > > The reality of cell/sector, even if it does go away, is not something we > should be concerned about. We do not want, nor do we need, to consider > primitives from the network bearer in our higher layer protocols. LoST > should deal only with location as input. > > Currently, there is an optimization step that occurs where routing > functions, which are co-hosted with determination functions, determine a > route based on these network bearer primitives (SAI is the most widely > used case). This should not be relevant to our discussion because we > have already drawn the line between the determination function and the > routing function. > > Just because we decide not to accept bearer primitives, doesn't mean that > we should ignore the realities of the situation when considering the form > of location that we handle. The reality is that location is subject to > uncertainty, and in mobile cases in particular, that uncertainty is more > than we might otherwise like. Yes, misrouting will occur, but obviously > we need to take what steps we can to address that. For the determination > side, this is obviously about improving location precision; for the > routing side, we obviously have a little way to go yet. > > Cheers, > Martin > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 28 22:57:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT8YV-0005Xb-DD; Thu, 28 Sep 2006 22:56:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT8YT-0005XU-Ds for ecrit@ietf.org; Thu, 28 Sep 2006 22:56:49 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT8YR-0004uj-Ty for ecrit@ietf.org; Thu, 28 Sep 2006 22:56:49 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k8T2uXCi022565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 28 Sep 2006 19:56:34 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k8T2rv8K012780; Thu, 28 Sep 2006 19:56:32 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Sep 2006 19:55:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Indication of PSAP Confidence Level in a LoSTQueryResponse Date: Thu, 28 Sep 2006 19:55:26 -0700 Message-ID: <21A52261514BE844AB662C1C21A29EA928995D@NAEX13.na.qualcomm.com> In-Reply-To: <00c801c6e2fe$97beeb00$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Indication of PSAP Confidence Level in a LoSTQueryResponse thread-index: AcbildWpIgjN8VccQziAddWTOkdXqgABJCNQABi1EoAAHN06YA== From: "Edge, Stephen" To: "Brian Rosen" , "Thomson, Martin" , "Henning Schulzrinne" X-OriginalArrivalTime: 29 Sep 2006 02:55:09.0505 (UTC) FILETIME=[AD02B310:01C6E372] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian I can't help commenting that uncertainty combined with a confidence level (implicit or explicit) would be very helpful when looking for someone or something because it tells you that area (or allows you to calculate the area) that has to be searched. For example, a 911 call from a large cell-sector where no more accurate location was available or could be provided by the caller might have to be answered by more than one emergency responder if time was critical. Conversely, if the area was pinned down to a single block or a few buildings, one would probably be enough. In general terms, search strategy can be dictated by location plus uncertainty plus confidence (plus other factors like environment, time of day, criticality etc.). If you have ever tried looking for someone in an airport or shopping mall versus a specific store or check-in area, you will know what I mean. Kind Regards Stephen -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Thursday, September 28, 2006 6:04 AM To: 'Thomson, Martin'; 'Henning Schulzrinne' Cc: 'ECRIT' Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a LoSTQueryResponse Martin I don't understand what this message is telling me. I think there is no discussion on what is input, beyond the one issue I was working on, which was whether there should be a representation of cell/sector beyond what we now have. The answer to that question, from NENA's point of view, is no. I think we all agree we have separated determination from routing. I have no idea what SAI is, but I suspect it's irrelevant to the present discussion. I don't know what a "bearer primitive" is, and I don't know if it has any relevance to the present discussion. I understand, in an engineering sense, what uncertainty represents. I accept that it represents "reality". I am beginning to have a whole lot more sympathy with the PSAP folks who are very frustrated with the engineers and their uncertainty, mostly because no one can tell them what the heck they can do with it. What is it that anyone can do with uncertainty? At the moment, I have heard nothing beyond ignore it. I understand that it's real. I have some vague notion that we should be able to use it intelligently. I have no idea what that is. So, while I'm okay with carrying it around, in the hope that some day we can use it, I'd rather not get into a lot of detail unless someone can say what the heck we DO with it. Right now, it's some number you can hide behind when the caller isn't where he is reported to be ignoring uncertainty. That's a useful thing in a legal sense, but doesn't really help anyone. Brian > -----Original Message----- > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > Sent: Wednesday, September 27, 2006 9:16 PM > To: Henning Schulzrinne; Brian Rosen > Cc: ECRIT > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a > LoSTQueryResponse >=20 > I see that this entire discussion is fraught with assumptions, some of > them misleading. >=20 > The reality of cell/sector, even if it does go away, is not something we > should be concerned about. We do not want, nor do we need, to consider > primitives from the network bearer in our higher layer protocols. LoST > should deal only with location as input. >=20 > Currently, there is an optimization step that occurs where routing > functions, which are co-hosted with determination functions, determine a > route based on these network bearer primitives (SAI is the most widely > used case). This should not be relevant to our discussion because we > have already drawn the line between the determination function and the > routing function. >=20 > Just because we decide not to accept bearer primitives, doesn't mean that > we should ignore the realities of the situation when considering the form > of location that we handle. The reality is that location is subject to > uncertainty, and in mobile cases in particular, that uncertainty is more > than we might otherwise like. Yes, misrouting will occur, but obviously > we need to take what steps we can to address that. For the determination > side, this is obviously about improving location precision; for the > routing side, we obviously have a little way to go yet. >=20 > Cheers, > Martin > ------------------------------------------------------------------------ -- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ -- > ---------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 29 07:48:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTGqx-0005Ld-Iu; Fri, 29 Sep 2006 07:48:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTGqw-0005LR-LK for ecrit@ietf.org; Fri, 29 Sep 2006 07:48:26 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTGqv-00056X-5n for ecrit@ietf.org; Fri, 29 Sep 2006 07:48:26 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GTGqp-0006Dm-Iv; Fri, 29 Sep 2006 06:48:19 -0500 From: "Brian Rosen" To: "'Edge, Stephen'" , "'Thomson, Martin'" , "'Henning Schulzrinne'" Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a LoSTQueryResponse Date: Fri, 29 Sep 2006 07:48:18 -0400 Message-ID: <02db01c6e3bd$2adf7710$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <21A52261514BE844AB662C1C21A29EA928995D@NAEX13.na.qualcomm.com> thread-index: AcbildWpIgjN8VccQziAddWTOkdXqgABJCNQABi1EoAAHN06YAASel8A X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Responders have experience looking for people who are not where they are "supposed" to be. What I am told is that the uncertainty/confidence information cannot be correlated to anything resembling "actionable" (to borrow a phrase) information different from a normal search mechanism, especially when confidence is not expressed in consistent terms. I come back to my original question. Location is displayed on a screen for a call taker. They have a map. It's easy to see how a point, or a hard polygon, would be represented. Tell me how you think a point with 50% confidence should be represented vs the same point with 70% confidence, using the same uncertainty shape. Suppose you had a search team. Tell me what you would tell that team which would be different if the confidence factors were 10, 50, 70 or 90%, or if the diameter of the uncertainty was 500m, 1km or 2km. I kind of understand that you might, if you could, vary the size of the team based on the size of the uncertainty area, although I challenge you to make that into actionable data if the confidence value varies. My search and rescue friends tell me that team size cannot realistically be significantly affected by this kind of information, but is more a function of local practice, terrain, etc. >From what they tell me, confidence/uncertainty information is NOT useful. Brian > -----Original Message----- > From: Edge, Stephen [mailto:sedge@qualcomm.com] > Sent: Thursday, September 28, 2006 10:55 PM > To: Brian Rosen; Thomson, Martin; Henning Schulzrinne > Cc: ECRIT > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a > LoSTQueryResponse > > Brian > > I can't help commenting that uncertainty combined with a confidence > level (implicit or explicit) would be very helpful when looking for > someone or something because it tells you that area (or allows you to > calculate the area) that has to be searched. For example, a 911 call > from a large cell-sector where no more accurate location was available > or could be provided by the caller might have to be answered by more > than one emergency responder if time was critical. Conversely, if the > area was pinned down to a single block or a few buildings, one would > probably be enough. In general terms, search strategy can be dictated by > location plus uncertainty plus confidence (plus other factors like > environment, time of day, criticality etc.). If you have ever tried > looking for someone in an airport or shopping mall versus a specific > store or check-in area, you will know what I mean. > > Kind Regards > > Stephen > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, September 28, 2006 6:04 AM > To: 'Thomson, Martin'; 'Henning Schulzrinne' > Cc: 'ECRIT' > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a > LoSTQueryResponse > > Martin > > I don't understand what this message is telling me. > I think there is no discussion on what is input, beyond the one issue I > was > working on, which was whether there should be a representation of > cell/sector beyond what we now have. The answer to that question, from > NENA's point of view, is no. > > I think we all agree we have separated determination from routing. I > have > no idea what SAI is, but I suspect it's irrelevant to the present > discussion. > > I don't know what a "bearer primitive" is, and I don't know if it has > any > relevance to the present discussion. > > I understand, in an engineering sense, what uncertainty represents. I > accept that it represents "reality". I am beginning to have a whole lot > more sympathy with the PSAP folks who are very frustrated with the > engineers > and their uncertainty, mostly because no one can tell them what the heck > they can do with it. What is it that anyone can do with uncertainty? > At > the moment, I have heard nothing beyond ignore it. I understand that > it's > real. I have some vague notion that we should be able to use it > intelligently. I have no idea what that is. > > So, while I'm okay with carrying it around, in the hope that some day we > can > use it, I'd rather not get into a lot of detail unless someone can say > what > the heck we DO with it. Right now, it's some number you can hide behind > when the caller isn't where he is reported to be ignoring uncertainty. > That's a useful thing in a legal sense, but doesn't really help anyone. > > Brian > > > -----Original Message----- > > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > > Sent: Wednesday, September 27, 2006 9:16 PM > > To: Henning Schulzrinne; Brian Rosen > > Cc: ECRIT > > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a > > LoSTQueryResponse > > > > I see that this entire discussion is fraught with assumptions, some of > > them misleading. > > > > The reality of cell/sector, even if it does go away, is not something > we > > should be concerned about. We do not want, nor do we need, to > consider > > primitives from the network bearer in our higher layer protocols. > LoST > > should deal only with location as input. > > > > Currently, there is an optimization step that occurs where routing > > functions, which are co-hosted with determination functions, determine > a > > route based on these network bearer primitives (SAI is the most widely > > used case). This should not be relevant to our discussion because we > > have already drawn the line between the determination function and the > > routing function. > > > > Just because we decide not to accept bearer primitives, doesn't mean > that > > we should ignore the realities of the situation when considering the > form > > of location that we handle. The reality is that location is subject > to > > uncertainty, and in mobile cases in particular, that uncertainty is > more > > than we might otherwise like. Yes, misrouting will occur, but > obviously > > we need to take what steps we can to address that. For the > determination > > side, this is obviously about improving location precision; for the > > routing side, we obviously have a little way to go yet. > > > > Cheers, > > Martin > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > [mf2] > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 29 22:04:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTUCK-0002Oh-GY; Fri, 29 Sep 2006 22:03:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTUCJ-0002Km-GB for ecrit@ietf.org; Fri, 29 Sep 2006 22:03:23 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTUCH-0002l6-RV for ecrit@ietf.org; Fri, 29 Sep 2006 22:03:23 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k8U232rx019837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 29 Sep 2006 19:03:03 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k8U22wHp012339; Fri, 29 Sep 2006 19:03:00 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 19:02:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Indication of PSAP Confidence Level in a LoSTQueryResponse Date: Fri, 29 Sep 2006 19:02:57 -0700 Message-ID: <21A52261514BE844AB662C1C21A29EA9289A77@NAEX13.na.qualcomm.com> In-Reply-To: <02db01c6e3bd$2adf7710$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Indication of PSAP Confidence Level in a LoSTQueryResponse thread-index: AcbildWpIgjN8VccQziAddWTOkdXqgABJCNQABi1EoAAHN06YAASel8AABxZ2bA= From: "Edge, Stephen" To: "Brian Rosen" , "Thomson, Martin" , "Henning Schulzrinne" X-OriginalArrivalTime: 30 Sep 2006 02:02:57.0860 (UTC) FILETIME=[8CD15840:01C6E434] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Brian Thanks for the comments. I appreciate that maybe uncertainty (and confidence) are not considered very useful for searching, although if it does or can affect the size of a search team, then it clearly has some impact. Neither of us are probably experts on conducting searches and it is possible that an optimum search may have to proceed in the same manner over each small area regardless of the size of the overall area (e.g. start by searching the area with the highest probability, gradually encompass areas with lower probability and continue until the target has been found or the initially defined search area has been completely searched). Knowing the most probable area at the start would allow you to concentrate resources on this and reduce search time if the area was reliable. So, for example, if the area included city blocks A to H but not I to Z, I would tell my search team to focus on A to H and spend less (or even no) time on I to Z until A to H had been searched. If I had no area information at all and suspected that the location point might not be accurate, I would be less inclined to ignore blocks I to Z. I suppose the real issue is being able to present (e.g. on a map) an area in which say a caller is expected to be with high probability (e.g. 95%) in a consistent manner. That is possible if the carrier provides to the PSAP an area of uncertainty (e.g. circle, ellipse, sector, polygon) together with a confidence level. For positioning methods that I am aware of, confidence normally varies from around 39% (e.g. natural result typical for an elliptical area) to 95% (e.g. delivered by some location servers following internal manipulation). The uncertainty area can be enlarged if confidence is less than the required level by making assumptions regarding the location probability distribution - e.g. a Gaussian distribution is often applicable in one dimension. For fairly small areas (or maybe even larger ones), more pessimistic assumptions could be used (meaning ones that would produce larger areas of uncertainty). This would call for SW tools on the PSAP side (or the transformation might be preformed in a GMLC or MPC). Ideally the transformation would be performed in the terminal (for terminal based positioning) or in the SMLC or PDE, but this will probably not be feasible in the short term. The results would clearly have to be evaluated through trials and/or through live experience. This is not, of course, an instantaneously applicable solution and it would most likely require cooperation and willingness within the industry as a whole (carriers, vendors and PSAPs). But it seems better than the rather adhoc situation now which has lead to results that are somewhat low common denominators. Kind Regards Stephen -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Friday, September 29, 2006 4:48 AM To: Edge, Stephen; 'Thomson, Martin'; 'Henning Schulzrinne' Cc: 'ECRIT' Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a LoSTQueryResponse Responders have experience looking for people who are not where they are "supposed" to be. What I am told is that the uncertainty/confidence information cannot be correlated to anything resembling "actionable" (to borrow a phrase) information different from a normal search mechanism, especially when confidence is not expressed in consistent terms. I come back to my original question. Location is displayed on a screen for a call taker. They have a map. It's easy to see how a point, or a hard polygon, would be represented. Tell me how you think a point with 50% confidence should be represented vs the same point with 70% confidence, using the same uncertainty shape. Suppose you had a search team. Tell me what you would tell that team which would be different if the confidence factors were 10, 50, 70 or 90%, or if the diameter of the uncertainty was 500m, 1km or 2km. I kind of understand that you might, if you could, vary the size of the team based on the size of the uncertainty area, although I challenge you to make that into actionable data if the confidence value varies. My search and rescue friends tell me that team size cannot realistically be significantly affected by this kind of information, but is more a function of local practice, terrain, etc. >From what they tell me, confidence/uncertainty information is NOT useful.=20 Brian > -----Original Message----- > From: Edge, Stephen [mailto:sedge@qualcomm.com] > Sent: Thursday, September 28, 2006 10:55 PM > To: Brian Rosen; Thomson, Martin; Henning Schulzrinne > Cc: ECRIT > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a > LoSTQueryResponse >=20 > Brian >=20 > I can't help commenting that uncertainty combined with a confidence > level (implicit or explicit) would be very helpful when looking for > someone or something because it tells you that area (or allows you to > calculate the area) that has to be searched. For example, a 911 call > from a large cell-sector where no more accurate location was available > or could be provided by the caller might have to be answered by more > than one emergency responder if time was critical. Conversely, if the > area was pinned down to a single block or a few buildings, one would > probably be enough. In general terms, search strategy can be dictated by > location plus uncertainty plus confidence (plus other factors like > environment, time of day, criticality etc.). If you have ever tried > looking for someone in an airport or shopping mall versus a specific > store or check-in area, you will know what I mean. >=20 > Kind Regards >=20 > Stephen > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, September 28, 2006 6:04 AM > To: 'Thomson, Martin'; 'Henning Schulzrinne' > Cc: 'ECRIT' > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a > LoSTQueryResponse >=20 > Martin >=20 > I don't understand what this message is telling me. > I think there is no discussion on what is input, beyond the one issue I > was > working on, which was whether there should be a representation of > cell/sector beyond what we now have. The answer to that question, from > NENA's point of view, is no. >=20 > I think we all agree we have separated determination from routing. I > have > no idea what SAI is, but I suspect it's irrelevant to the present > discussion. >=20 > I don't know what a "bearer primitive" is, and I don't know if it has > any > relevance to the present discussion. >=20 > I understand, in an engineering sense, what uncertainty represents. I > accept that it represents "reality". I am beginning to have a whole lot > more sympathy with the PSAP folks who are very frustrated with the > engineers > and their uncertainty, mostly because no one can tell them what the heck > they can do with it. What is it that anyone can do with uncertainty? > At > the moment, I have heard nothing beyond ignore it. I understand that > it's > real. I have some vague notion that we should be able to use it > intelligently. I have no idea what that is. >=20 > So, while I'm okay with carrying it around, in the hope that some day we > can > use it, I'd rather not get into a lot of detail unless someone can say > what > the heck we DO with it. Right now, it's some number you can hide behind > when the caller isn't where he is reported to be ignoring uncertainty. > That's a useful thing in a legal sense, but doesn't really help anyone. >=20 > Brian >=20 > > -----Original Message----- > > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > > Sent: Wednesday, September 27, 2006 9:16 PM > > To: Henning Schulzrinne; Brian Rosen > > Cc: ECRIT > > Subject: RE: [Ecrit] Indication of PSAP Confidence Level in a > > LoSTQueryResponse > > > > I see that this entire discussion is fraught with assumptions, some of > > them misleading. > > > > The reality of cell/sector, even if it does go away, is not something > we > > should be concerned about. We do not want, nor do we need, to > consider > > primitives from the network bearer in our higher layer protocols. > LoST > > should deal only with location as input. > > > > Currently, there is an optimization step that occurs where routing > > functions, which are co-hosted with determination functions, determine > a > > route based on these network bearer primitives (SAI is the most widely > > used case). This should not be relevant to our discussion because we > > have already drawn the line between the determination function and the > > routing function. > > > > Just because we decide not to accept bearer primitives, doesn't mean > that > > we should ignore the realities of the situation when considering the > form > > of location that we handle. The reality is that location is subject > to > > uncertainty, and in mobile cases in particular, that uncertainty is > more > > than we might otherwise like. Yes, misrouting will occur, but > obviously > > we need to take what steps we can to address that. For the > determination > > side, this is obviously about improving location precision; for the > > routing side, we obviously have a little way to go yet. > > > > Cheers, > > Martin > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > [mf2] >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit