From ecrit-bounces@ietf.org Wed May 02 10:34:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjFuT-0002cg-DW; Wed, 02 May 2007 10:34:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjFuR-0002ca-FX for ecrit@ietf.org; Wed, 02 May 2007 10:34:23 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjFuQ-0007W7-94 for ecrit@ietf.org; Wed, 02 May 2007 10:34:23 -0400 Received: from [10.0.1.110] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 02 May 2007 10:34:21 -0400 id 015880B2.4638A16D.00001D2E In-Reply-To: <4636481B.8050908@gmx.net> References: <4636481B.8050908@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9ECB5069-6F98-4FCC-90C1-D1BF61D9780F@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Location Hiding: Summary Date: Wed, 2 May 2007 10:34:19 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 On Apr 30, 2007, at 3:48 PM, Hannes Tschofenig wrote: > To allow everyone to add a comments to the text I have copied the > text to this Wiki: > http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/ > LocationHiding Alright, I've added comments. Thanks Hannes. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 04 11:35:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjzoc-0006rw-GD; Fri, 04 May 2007 11:35:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjzob-0006ro-FC; Fri, 04 May 2007 11:35:25 -0400 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hjzoa-0002S7-Qj; Fri, 04 May 2007 11:35:25 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 8ED9F2010A; Fri, 4 May 2007 11:35:24 -0400 (EDT) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31390-07-2; Fri, 4 May 2007 11:35:23 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id C736D200CE; Fri, 4 May 2007 11:35:20 -0400 (EDT) In-Reply-To: <4612AFB3.6090407@gmx.net> To: Hannes.Tschofenig@gmx.net, Bernard Aboba Subject: Re: [Ecrit] Review of IEEE 802.11k: Urgent! MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: peter_blatherwick@mitel.com Date: Fri, 4 May 2007 11:35:18 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 05/04/2007 11:35:19 AM, Serialize complete at 05/04/2007 11:35:19 AM X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.7 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Cc: GEOPRIV , "Manfred Arndt \(HP-ProCurve\)" , dstanley@arubanetworks.com, 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="===============0303081482==" Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============0303081482== Content-Type: multipart/alternative; boundary="=_alternative 0055A0E3852572D1_=" This is a multipart message in MIME format. --=_alternative 0055A0E3852572D1_= Content-Type: text/plain; charset="US-ASCII" Hannes, Bernard, all, I have finally had a chance to go through the 802.11k document in some detail and have some comments. (Very sorry for the delay! All the usual excuses apply.) I have also included the other reviewers and interested parties here directly. My apologies in advance if (when) I mess up terminology and details -- I am certainly far from deep on 802.11. THE BIG COMMENT: My main comment is that I am very concerned that 802.11k does not reuse IEEE 802.1AB Link Layer Discovery Protocol (LLDP) as the mechanism to return device-specific location. More specifically, I believe LLDP-MED (ANSI/TIA-1057, a VoIP-specific extension of 802.1AB) is the appropriate means to return location or other device-specific parameters of similar nature in WLAN environments. In 802.11k, this appears to be happening through a lower level mechanisms (Measurement Request Frames), different from LLDP. My fear is this will result in multiple different ways to return the very same location information at L2, dependent on the specific 802 network technology. Such differences and proliferation of methods would, I believe, be very problematic for Emergency Call Service and other location-based applications, so should be avoided at all costs. Also note that LLDP-MED is the *one* method for location determination at L2 currently specified in IETF ECRIT (of 3 methods total, at various layers). In addition, reuse of LLDP / LLDP-MED for location and similar purposes (not related to the measurement itself) would have several other benefits: o LLDP and extensions to it can support any 802 link layer, or could be readily extended to do so (more on this below), so could be common to all; o Since LLDP is above the MAC layer, it can be implemented without driver-level changes, making it much easier to deploy; o LLDP/LLDP-MED is already deployed in VoIP endpoints, and that deployment is growing, so forms a base for moving the same types of information in WLAN environments as well (noting also that LLDP-MED can already support AP-specific location today); o LLDP/LLDP-MED, with appropriate extension, could also be used to carry other device-specific information in WLAN environments, such as device-specific LAN policy or others (LLDP-MED is already used for this today in wired environments, and can already carry AP-specific information along these lines). As further background, 802.1AB is currently in revision process ("ABrev"), so it would a very opportune time to define appropriate extensions to allow for device-specific information exchange in WLAN environments. One proposal is to allow 802.1AB frames to be addressed to the endpoint device MAC (rather than a broadcast seen by all endpoints on the same SSID), which would allow 802.11i to be used to address individual devices through the corresponding virtual port. If I understand correctly (which may or may not be the case) this would allow LLDP to be used for device-specific exchanges, as well as provide security for those exchanges. Comments related to this are about to be submitted to the ABrev group as well. ADDITIONAL COMMENTS: o Section 7.3.2.21.9 & ..22.9, adding to Brian Rosen's comment, yes it does appear that the location information carried would not be secured, since encryption does not apply to 802.11 action frames. Additionally, these frames can be exchanged before 802.1X completes (not the case with LLDP). I believe this is a serious issues as well, and could potentially preclude its use in Geopriv. o Section 7.3.2.21.9 & ..22.9, only geolocation LCI format is supported. For compatibility with IETF ECRIT and Geopriv, this should also be capable of carrying Civic Location format (RFC 4776, or LLDP-MED). Additional formats may be desirable in future, which may be difficult to deploy after the fact. --------------------------------------------------- I hope this helps clarify the situation and acts as useful input to 802.11k and others. Regards, Peter Blatherwick (Editor, LLDP-MED, ANSI/TIA-1057) Hannes Tschofenig 03.04.07 15:49 To: ECRIT , GEOPRIV cc: Bernard Aboba Subject: [Ecrit] Review of IEEE 802.11k: Urgent! Hi all, based on the IETF ECRIT / IEEE information sharing event at IETF#68 it was indicated that a review of IEEE documents would be useful. Bernard Aboba has provided me with information about the documents that should be reviewed. Thank you, Bernard. We should start with IEEE 802.11k (with a focus on the location information format specific sections). Unfortunately, the document is already in sponsor ballot and a review needs to be provided very soon. Who would be willing to review the document? I will send the username/passwd to fetch the latest document version to the reviewers. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --=_alternative 0055A0E3852572D1_= Content-Type: text/html; charset="US-ASCII"
Hannes, Bernard, all,  

I have finally had a chance to go through the 802.11k document in some detail and have some comments.  (Very sorry for the delay!  All the usual excuses apply.)  I have also included the other reviewers and interested parties here directly.  My apologies in advance if (when) I mess up terminology and details -- I am certainly far from deep on 802.11.  

THE BIG COMMENT:

My main comment is that I am very concerned that 802.11k does not  reuse IEEE 802.1AB Link Layer Discovery Protocol (LLDP) as the mechanism to return device-specific location.  More specifically, I believe LLDP-MED (ANSI/TIA-1057, a VoIP-specific extension of 802.1AB) is the appropriate means to return location or other device-specific parameters of similar nature in WLAN environments.  In 802.11k, this appears to be happening through a lower level mechanisms (Measurement Request Frames), different from LLDP.  My fear is this will result in multiple different ways to return the very same location information at L2, dependent on the specific 802 network technology.  Such differences and proliferation of methods would, I believe, be very problematic for Emergency Call Service and other location-based applications, so should be avoided at all costs.  Also note that LLDP-MED is the *one* method for location determination at L2 currently specified in IETF ECRIT (of 3 methods total, at various layers).  

In addition, reuse of LLDP / LLDP-MED for location and similar purposes (not related to the measurement itself) would have several other benefits:

o LLDP and extensions to it can support any 802 link layer, or could be readily extended to do so (more on this below), so could be common to all;  

o Since LLDP is above the MAC layer, it can be implemented without driver-level changes, making it much easier to deploy;

o LLDP/LLDP-MED is already deployed in VoIP endpoints, and that deployment is growing, so forms a base for moving the same types of information in WLAN environments as well (noting also that LLDP-MED can already support AP-specific location today);

o LLDP/LLDP-MED, with appropriate extension, could also be used to carry other device-specific information in WLAN environments, such as device-specific LAN policy or others (LLDP-MED is already used for this today in wired environments, and can already carry AP-specific information along these lines).  

As further background, 802.1AB is currently in revision process ("ABrev"), so it would a very opportune time to define appropriate extensions to allow for device-specific information exchange in WLAN environments.  One proposal is to allow 802.1AB frames to be addressed to the endpoint device MAC (rather than a broadcast seen by all endpoints on the same SSID), which would allow 802.11i to be used to address individual devices through the corresponding virtual port.  If I understand correctly (which may or may not be the case) this would allow LLDP to be used for device-specific exchanges, as well as provide security for those exchanges.  Comments related to this are about to be submitted to the ABrev group as well.  


ADDITIONAL COMMENTS:  

o Section 7.3.2.21.9 & ..22.9, adding to Brian Rosen's comment, yes it does appear that the location information carried would not be secured, since encryption does not apply to 802.11 action frames.  Additionally, these frames can be exchanged before 802.1X completes (not the case with LLDP).  I believe this is a serious issues as well, and could potentially preclude its use in Geopriv.  

o Section 7.3.2.21.9 & ..22.9, only geolocation LCI format is supported.  For compatibility with IETF ECRIT and Geopriv, this should also be capable of carrying Civic Location format (RFC 4776, or LLDP-MED).  Additional formats may be desirable in future, which may be difficult to deploy after the fact.  

---------------------------------------------------

I hope this helps clarify the situation and acts as useful input to 802.11k and others.  

Regards,
Peter Blatherwick
(Editor, LLDP-MED, ANSI/TIA-1057)





Hannes Tschofenig <Hannes.Tschofenig@gmx.net>

03.04.07 15:49

       
        To:        ECRIT <ecrit@ietf.org>, GEOPRIV <geopriv@ietf.org>
        cc:        Bernard Aboba <bernard_aboba@hotmail.com>
        Subject:        [Ecrit] Review of IEEE 802.11k: Urgent!



Hi all,

based on the IETF ECRIT / IEEE information sharing event at IETF#68 it
was indicated that a review of IEEE documents would be useful. Bernard
Aboba has provided me with information about the documents that should
be reviewed. Thank you, Bernard.

We should start with IEEE 802.11k (with a focus on the location
information format specific sections). Unfortunately, the document is
already in sponsor ballot and a review needs to be provided very soon.
Who would be willing to review the document? I will send the
username/passwd to fetch the latest document version to the reviewers.

Ciao
Hannes


_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit
--=_alternative 0055A0E3852572D1_=-- --===============0303081482== 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 --===============0303081482==-- From ecrit-bounces@ietf.org Fri May 04 13:34:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hk1fb-0003Xw-Q3; Fri, 04 May 2007 13:34:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hk1fb-0003Vz-2G for ecrit@ietf.org; Fri, 04 May 2007 13:34:15 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hk1fZ-0002nd-SM for ecrit@ietf.org; Fri, 04 May 2007 13:34:15 -0400 Received: from po2.bbn.com ([128.33.0.56]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Hk1fZ-00029y-59 for ecrit@ietf.org; Fri, 04 May 2007 13:34:13 -0400 Received: from [127.0.0.1] (col-dhcp33-244-161.bbn.com [128.33.244.161]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id l44HYCw01556 for ; Fri, 4 May 2007 13:34:12 -0400 (EDT) Message-ID: <463B6EAB.7060604@bbn.com> Date: Fri, 04 May 2007 13:34:35 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [Ecrit] Location hiding: Consensus? X-BeenThere: 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, the discussion of location hiding seems to have died down. Does that mean that we've reached some consensus? Are we going with some variant option #1? --Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 04 14:01:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hk26K-00086c-N6; Fri, 04 May 2007 14:01:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hk26J-00086U-Ss for ecrit@ietf.org; Fri, 04 May 2007 14:01:51 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hk26I-0006iX-Dn for ecrit@ietf.org; Fri, 04 May 2007 14:01:51 -0400 Received: (qmail invoked by alias); 04 May 2007 18:01:48 -0000 Received: from p54986C1B.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.108.27] by mail.gmx.net (mp016) with SMTP; 04 May 2007 20:01:48 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/eAyEEW7neH0/aiYKODIB5Kt0qgW4thJyWtCwdJ2 SNSKkH6j+JxT4U Message-ID: <463B750C.6050106@gmx.net> Date: Fri, 04 May 2007 20:01:48 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Richard Barnes Subject: Re: [Ecrit] Location hiding: Consensus? References: <463B6EAB.7060604@bbn.com> In-Reply-To: <463B6EAB.7060604@bbn.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: cf4fa59384e76e63313391b70cd0dd25 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 hope that people have had time to study the Wiki page http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/LocationHiding Richard Barnes wrote: > So, the discussion of location hiding seems to have died down. Does > that mean that we've reached some consensus? Are we going with some > variant option #1? > > --Richard > > > _______________________________________________ > 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 May 04 14:22:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hk2QO-0005dn-TH; Fri, 04 May 2007 14:22:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hk2QN-0005di-Va for ecrit@ietf.org; Fri, 04 May 2007 14:22:35 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hk2QM-00084W-Pr for ecrit@ietf.org; Fri, 04 May 2007 14:22:35 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Fri, 04 May 2007 14:22:33 -0400 id 0158813F.463B79E9.0000623D In-Reply-To: <463B6EAB.7060604@bbn.com> References: <463B6EAB.7060604@bbn.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <31D7CCEF-4BDA-489F-B0BA-B61C66253CA6@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Location hiding: Consensus? Date: Fri, 4 May 2007 14:22:32 -0400 To: Richard Barnes X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 On May 4, 2007, at 1:34 PM, Richard Barnes wrote: > So, the discussion of location hiding seems to have died down. > Does that mean that we've reached some consensus? Are we going > with some variant option #1? I'd appreciate if some of the issues raised were addressed. See the wiki page. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 04 15:43:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hk3h4-0002q3-KE; Fri, 04 May 2007 15:43:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hk3h3-0002py-Q4 for ecrit@ietf.org; Fri, 04 May 2007 15:43:53 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hk3h0-0003Aw-Gs for ecrit@ietf.org; Fri, 04 May 2007 15:43:53 -0400 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l44Jh1D28432 for ; Fri, 4 May 2007 19:43:01 GMT Received: from [47.130.18.68] ([47.130.18.68] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 May 2007 15:43:44 -0400 Message-ID: <463B8CBE.2060301@nortel.com> Date: Fri, 04 May 2007 15:42:54 -0400 From: "Tom-PT Taylor" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 May 2007 19:43:44.0865 (UTC) FILETIME=[869D9510:01C78E84] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Subject: [Ecrit] Priority header field as emergency call marker X-BeenThere: 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've gone back through my 2004-2006 archives, but haven't located any discussion of the use of the Priority header field to mark an emergency call outside of a brief exchange that compared it against RPH. Why did we not choose that approach to satisfy the requirement? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 04 15:58:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hk3vT-0007VD-RE; Fri, 04 May 2007 15:58:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hk3vS-0007Uu-AW for ecrit@ietf.org; Fri, 04 May 2007 15:58:46 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hk3vR-00080I-2u for ecrit@ietf.org; Fri, 04 May 2007 15:58:46 -0400 Received: from [160.39.255.12] (dyn-160-39-255-12.dyn.columbia.edu [160.39.255.12]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l44JwZ9F010496 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 4 May 2007 15:58:40 -0400 (EDT) In-Reply-To: <463B8CBE.2060301@nortel.com> References: <463B8CBE.2060301@nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Priority header field as emergency call marker Date: Fri, 4 May 2007 16:00:20 -0400 To: "Tom-PT Taylor" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 don't recall the whole discussion, but one reason was that the two issues (type of call, prioritization of processing) are orthogonal. Not all emergency calls get or deserve priority and not all priority calls are emergency calls. On May 4, 2007, at 3:42 PM, Tom-PT Taylor wrote: > I've gone back through my 2004-2006 archives, but haven't located > any discussion of the use of the Priority header field to mark an > emergency call outside of a brief exchange that compared it against > RPH. Why did we not choose that approach to satisfy the requirement? > > _______________________________________________ > 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 May 04 16:03:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hk3zt-0000uQ-V6; Fri, 04 May 2007 16:03:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hk3zt-0000uL-AG for ecrit@ietf.org; Fri, 04 May 2007 16:03:21 -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 1Hk3zs-0001LX-2X for ecrit@ietf.org; Fri, 04 May 2007 16:03:21 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Fri, 04 May 2007 16:03:19 -0400 id 01588103.463B9187.000077CA In-Reply-To: References: <463B8CBE.2060301@nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7815401B-B368-4791-A181-0DD9F5A67D30@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Priority header field as emergency call marker Date: Fri, 4 May 2007 16:03:18 -0400 To: Tom-PT Taylor , Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 That's my recollection as well. A lot of this discussion is probably found in the meeting minutes, btw. I know it has been discussed in the meetings. -andy On May 4, 2007, at 4:00 PM, Henning Schulzrinne wrote: > I don't recall the whole discussion, but one reason was that the > two issues (type of call, prioritization of processing) are > orthogonal. Not all emergency calls get or deserve priority and not > all priority calls are emergency calls. > > On May 4, 2007, at 3:42 PM, Tom-PT Taylor wrote: > >> I've gone back through my 2004-2006 archives, but haven't located >> any discussion of the use of the Priority header field to mark an >> emergency call outside of a brief exchange that compared it >> against RPH. Why did we not choose that approach to satisfy the >> requirement? >> >> _______________________________________________ >> 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 May 04 20:22:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hk82U-0007nj-NM; Fri, 04 May 2007 20:22:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hk82S-0007ne-Vu for ecrit@ietf.org; Fri, 04 May 2007 20:22:16 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hk82Q-0001d8-Mm for ecrit@ietf.org; Fri, 04 May 2007 20:22:16 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l450M8EN029701 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 4 May 2007 20:22:09 -0400 (EDT) In-Reply-To: <31D7CCEF-4BDA-489F-B0BA-B61C66253CA6@hxr.us> References: <463B6EAB.7060604@bbn.com> <31D7CCEF-4BDA-489F-B0BA-B61C66253CA6@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <90ED6EE1-E045-4A40-8B63-1D87C0017217@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Location hiding: Consensus? Date: Fri, 4 May 2007 20:22:06 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 > Issue HR-1 This should not be a requirement. Not all IP address > based location determination systems are that accurate. > Additionally, giving away course location information should not be > required to hide location. Course location information even at the > country level is useful commercially. One such example is Google, > which uses IP address location determination at the country level > to route users to language specific start pages. Access networks > should be allowed to charge for location information that is as > course as this, since it is a valuable asset on today's Internet. - > andy We are not in the business of creating business opportunities for carriers at the expense of others. As long as our main 'customers' don't object, it's not our role to make life difficult and less debugable for emergency services. Given that GeoMind and others are giving away rough location information, the value of such information is in doubt in any event. > Issue 1-3 UAs must now be forbidden from conveying dereferenced > location information. I don't see why. LocationConveyance supports multiple locations. > Issue 1-4 The semantic difference regarding authorization/ > nonauthorization of location information is lost, making it > difficult for UAs to know if they truly are not authorized to get > true location information. This introduces ambiquity, which should > be avoided for emergency situations. I can't parse this. There is little ambiguity in a 403 Forbidden HTTP response, but in any event, the UA without credentials would get location, not a refusal, just not with the same accuracy. > Issue 2a-2 The work around LoST discovery needs to be completed. > This is not specific to location hiding. The issue is that LoST discovery will likely return multiple servers. I had earlier pointed out at least three plausible operators (ISP, VSP, general public service), provided by several different configuration mechanisms. The UA has to use the right one, as things will fail otherwise. Also, from an operator perspective, here the landline ISP has to operate a LoST resolver, instead of dumb "return fixed location" server. http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/ LocationHiding On May 4, 2007, at 2:22 PM, Andrew Newton wrote: > > On May 4, 2007, at 1:34 PM, Richard Barnes wrote: > >> So, the discussion of location hiding seems to have died down. >> Does that mean that we've reached some consensus? Are we going >> with some variant option #1? > > I'd appreciate if some of the issues raised were addressed. See > the wiki page. > > -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 May 06 03:00:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkajD-0004vM-Oi; Sun, 06 May 2007 03:00:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkajC-0004ux-2p for ecrit@ietf.org; Sun, 06 May 2007 03:00:18 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HkajA-0007b0-Ls for ecrit@ietf.org; Sun, 06 May 2007 03:00:18 -0400 Received: (qmail invoked by alias); 06 May 2007 07:00:14 -0000 Received: from p5498469B.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.70.155] by mail.gmx.net (mp058) with SMTP; 06 May 2007 09:00:14 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19OBHRrdQ9OgPVEstx9ZZw6eppjsypmCZ46VzjRDA HcaqT0l4S7JuaL Message-ID: <463D7CFD.6030100@gmx.net> Date: Sun, 06 May 2007 09:00:13 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: GEOPRIV , 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: cf4fa59384e76e63313391b70cd0dd25 Cc: Bernard Aboba , "Wijnen, Bert \(Bert\)" Subject: [Ecrit] IEEE Document Reviews X-BeenThere: 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 solicited review comments for IEEE 802.11k. Dan, Peter and Brian have sent review comments. Thanks a lot! I have copied the comments to the following webpage: http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/ReviewIEEEDocuments Bernard, Bert, Dan: Can you forward the review comments to the IEEE? ECRIT, GEOPRIV: We need to review some other documents as well, namely IEEE 802.11u, IEEE 802.11v, IEEE 802.11y, and potentially IEEE 802.16. If someone is willing todo a review please send me a mail. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun May 06 13:11:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkkGr-00063R-IM; Sun, 06 May 2007 13:11:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkkGq-00063M-5F for ecrit@ietf.org; Sun, 06 May 2007 13:11:40 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HkkGo-00040L-Mf for ecrit@ietf.org; Sun, 06 May 2007 13:11:40 -0400 Received: (qmail invoked by alias); 06 May 2007 17:11:37 -0000 Received: from p5498469B.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.70.155] by mail.gmx.net (mp052) with SMTP; 06 May 2007 19:11:37 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+NlfsZfHONYb2BD/HMwn7dR/BGnlJ/Ws3XhOjZvi bzoGHTHmVyFX9U Message-ID: <463E0C46.4000901@gmx.net> Date: Sun, 06 May 2007 19:11:34 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) 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: 057ebe9b96adec30a7efb2aeda4c26a4 Subject: [Ecrit] ECRIT WG Status Update X-BeenThere: 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, here is a short working group status update: http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/EcritStatusUpdate * WG documents 1) LoST Draft update necessary with respect to location profiles. It seems to be necessary to support a location profile that can express polygons. ACTION ITEM: Hannes to start draft update asap. 2) Phone BCP The document requires more reviews and more work. For example, text from SIP Location Conveyance and from PIDF-LO profile has been moved to this document. A couple of expert reviews are also pending. ACTION ITEM: Hannes to ensure that reviews are provided. 3) Framework The document also requires more work given that it has not seen enough review. The location hiding discussion needs to be reflected in the document as well. After another draft update the chairs will solicit further review requests. A couple of expert reviews are also pending. ACTION ITEM: Hannes to ensure that reviews are provided. 4) DHCP-based LoST discovery Review comments from the DHC group have been provided and another WGLC (together with the DHC group) is necessary. Here is my review request and 2 responses: http://www1.ietf.org/mail-archive/web/dhcwg/current/msg07234.html http://www1.ietf.org/mail-archive/web/ecrit/current/msg03735.html http://www1.ietf.org/mail-archive/web/dhcwg/current/msg07236.html ACTION ITEM: Marc to initiate a WGLC after the draft update is available. 5) Mapping Architecture This document seems fairly complete and passed WGLC already. Unfortunately, we haven't seen a lot of review comments. 2 expert reviews are also missing. ACTION ITEM: Marc to find a few reviewers. * Review of IEEE documents IEEE 802.11k review complete. More reviewers for other documents solicited. A webpage for the reviews is available here: http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/ReviewIEEEDocuments ACTION ITEM: Hannes to check with Robert Sparks regarding sharing the workload. * Hiding (Partial) Locations Discussion After a long discussion we have a couple of solution proposals: http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/LocationHiding We need to decide for a particular approach before we update our documents. ACTION ITEM: Hannes to make a call for consensus * Follow-Up regarding "IETF ECRIT / IEEE Information Sharing Event @ IETF#68" ACTION ITEM: Hannes to initiate a discussion * ATIS ESIF Document review Document review and response to liaison request still not done. ACTION ITEM: Hannes & Marc & Robert to initiate some actions. * Charter Update The charter update of February still hasn't been provided. In the meanwhile it is pretty obsolete since another charter update is required. ACTION ITEM: Hannes to submit a new charter update. * Follow-Up "Interact with the IAB" The IAB Tech Chat on Emergency Services presentation took place on the 28th February 2007. See slides here: http://www.tschofenig.priv.at/twiki/pub/EmergencyServices/IetfEcritRoadMap/Emergency-Services.ppt Not quite clear what needs to be done. ACTION ITEM: Hannes to figure out what has to be done. Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun May 06 13:25:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkkTs-0006Wp-J9; Sun, 06 May 2007 13:25:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkkTr-0006Wj-2j for ecrit@ietf.org; Sun, 06 May 2007 13:25:07 -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 1HkkTp-0005k8-St for ecrit@ietf.org; Sun, 06 May 2007 13:25:07 -0400 Received: from [10.0.1.110] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Sun, 06 May 2007 13:25:03 -0400 id 01588516.463E0F6F.00000FE9 In-Reply-To: <463E0C46.4000901@gmx.net> References: <463E0C46.4000901@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <51D5CF5C-F164-4D09-A1B3-C06463E68DC2@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] ECRIT WG Status Update Date: Sun, 6 May 2007 13:24:57 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 On May 6, 2007, at 1:11 PM, Hannes Tschofenig wrote: > 1) LoST > > Draft update necessary with respect to location profiles. It seems > to be necessary to support a location profile that can express > polygons. There's more than that. There were a couple of items from wglc as well. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun May 06 19:42:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkqMw-0002mX-Ll; Sun, 06 May 2007 19:42:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkqMv-0002mS-D7 for ecrit@ietf.org; Sun, 06 May 2007 19:42:21 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HkqMu-0003VK-4y for ecrit@ietf.org; Sun, 06 May 2007 19:42:21 -0400 X-SEF-Processed: 5_0_0_910__2007_05_06_18_49_13 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sun, 06 May 2007 18:49:13 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 6 May 2007 18:42:15 -0500 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] Location hiding: Consensus? Date: Sun, 6 May 2007 18:42:13 -0500 Message-ID: In-Reply-To: <463B6EAB.7060604@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location hiding: Consensus? Thread-Index: AceOcoKTgBe/4+0mTIG1QzhiIMcVjwBxZPSA From: "Winterbottom, James" To: "Richard Barnes" , "ECRIT" X-OriginalArrivalTime: 06 May 2007 23:42:15.0684 (UTC) FILETIME=[2D5AC440:01C79038] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 No!=0D=0A=0D=0AI saw at least 3 votes for solution 3.=0D=0A=0D=0A=0D=0A=0D=0A= > -----Original Message-----=0D=0A> From: Richard Barnes [mailto:rbarnes@bb= n.com]=0D=0A> Sent: Saturday, 5 May 2007 3:35 AM=0D=0A> To: ECRIT=0D=0A> Su= bject: [Ecrit] Location hiding: Consensus=3F=0D=0A>=20=0D=0A> So, the discu= ssion of location hiding seems to have died down. Does=0D=0A> that mean th= at we've reached some consensus=3F Are we going with some=0D=0A> variant o= ption #1=3F=0D=0A>=20=0D=0A> --Richard=0D=0A>=20=0D=0A>=20=0D=0A> _________= ______________________________________=0D=0A> Ecrit mailing list=0D=0A> Ecr= it@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A= ---------------------------------------------------------------------------= ---------------------=0D=0AThis message is for the designated recipient onl= y and may=0D=0Acontain privileged, proprietary, or otherwise private inform= ation. =20=0D=0AIf you have received it in error, please notify the sender=0D= =0Aimmediately and delete the original. Any unauthorized use of=0D=0Athis = email is prohibited.=0D=0A-------------------------------------------------= -----------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun May 06 21:52:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HksOh-0007Zc-Rl; Sun, 06 May 2007 21:52:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HksOh-0007ZU-7e; Sun, 06 May 2007 21:52:19 -0400 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HksOf-0003ia-TN; Sun, 06 May 2007 21:52:19 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 9C79520023; Sun, 6 May 2007 21:52:17 -0400 (EDT) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13169-06; Sun, 6 May 2007 21:52:16 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id E0E282001C; Sun, 6 May 2007 21:52:16 -0400 (EDT) In-Reply-To: <463D7CFD.6030100@gmx.net> To: Hannes Tschofenig Subject: Re: [Ecrit] IEEE Document Reviews MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: peter_blatherwick@mitel.com Date: Sun, 6 May 2007 21:52:15 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 05/06/2007 09:52:13 PM, Serialize complete at 05/06/2007 09:52:13 PM X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.3 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: Bernard Aboba , GEOPRIV , ECRIT , "Wijnen, Bert \(Bert\)" X-BeenThere: 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="===============1474239149==" Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============1474239149== Content-Type: multipart/alternative; boundary="=_alternative 000A428E852572D4_=" This is a multipart message in MIME format. --=_alternative 000A428E852572D4_= Content-Type: text/plain; charset="US-ASCII" Hi, Thanks for posting Hannes. Sure, I will try to review (... with the usual caveats on timeliness and depth of knowledge ;-) Please send links. It would be really useful if someone cold aim us all at relevant pieces of the various specs to plough through! -- Peter Hannes Tschofenig 06.05.07 03:00 To: GEOPRIV , ECRIT cc: Bernard Aboba , "Wijnen, Bert \(Bert\)" Subject: [Ecrit] IEEE Document Reviews Hi all, we have solicited review comments for IEEE 802.11k. Dan, Peter and Brian have sent review comments. Thanks a lot! I have copied the comments to the following webpage: http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/ReviewIEEEDocuments Bernard, Bert, Dan: Can you forward the review comments to the IEEE? ECRIT, GEOPRIV: We need to review some other documents as well, namely IEEE 802.11u, IEEE 802.11v, IEEE 802.11y, and potentially IEEE 802.16. If someone is willing todo a review please send me a mail. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --=_alternative 000A428E852572D4_= Content-Type: text/html; charset="US-ASCII"
Hi,

Thanks for posting Hannes.  

Sure, I will try to review (... with the usual caveats on timeliness and depth of knowledge ;-)   Please send links.  

It would be really useful  if someone cold aim us all at relevant pieces of the various specs to plough through!  

-- Peter




Hannes Tschofenig <Hannes.Tschofenig@gmx.net>

06.05.07 03:00

       
        To:        GEOPRIV <geopriv@ietf.org>, ECRIT <ecrit@ietf.org>
        cc:        Bernard Aboba <bernard_aboba@hotmail.com>, "Wijnen,        Bert \(Bert\)" <bwijnen@alcatel-lucent.com>
        Subject:        [Ecrit] IEEE Document Reviews



Hi all,

we have solicited review comments for IEEE 802.11k. Dan, Peter and Brian
have sent review comments. Thanks a lot!
I have copied the comments to the following webpage:
http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/ReviewIEEEDocuments

Bernard, Bert, Dan: Can you forward the review comments to the IEEE?

ECRIT, GEOPRIV: We need to review some other documents as well, namely
IEEE 802.11u, IEEE 802.11v, IEEE 802.11y, and potentially IEEE 802.16.
If someone is willing todo a review please send me a mail.

Ciao
Hannes


_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit
--=_alternative 000A428E852572D4_=-- --===============1474239149== 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 --===============1474239149==-- From ecrit-bounces@ietf.org Mon May 07 14:28:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl7wH-0004jf-8l; Mon, 07 May 2007 14:28:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl7wG-0004ja-Cm for ecrit@ietf.org; Mon, 07 May 2007 14:28: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 1Hl7wF-0006E3-3t for ecrit@ietf.org; Mon, 07 May 2007 14:28:00 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Mon, 07 May 2007 14:27:58 -0400 id 015880AF.463F6FAE.000033D9 In-Reply-To: <90ED6EE1-E045-4A40-8B63-1D87C0017217@cs.columbia.edu> References: <463B6EAB.7060604@bbn.com> <31D7CCEF-4BDA-489F-B0BA-B61C66253CA6@hxr.us> <90ED6EE1-E045-4A40-8B63-1D87C0017217@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Location hiding: Consensus? Date: Mon, 7 May 2007 14:27:56 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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 On May 4, 2007, at 8:22 PM, Henning Schulzrinne wrote: >> Issue HR-1 This should not be a requirement. Not all IP address >> based location determination systems are that accurate. >> Additionally, giving away course location information should not >> be required to hide location. Course location information even at >> the country level is useful commercially. One such example is >> Google, which uses IP address location determination at the >> country level to route users to language specific start pages. >> Access networks should be allowed to charge for location >> information that is as course as this, since it is a valuable >> asset on today's Internet. -andy > > We are not in the business of creating business opportunities for > carriers at the expense of others. As long as our main 'customers' > don't object, it's not our role to make life difficult and less > debugable for emergency services. Given that GeoMind and others are > giving away rough location information, the value of such > information is in doubt in any event. What!? I don't understand your response and can't seem how it is even directly relevant to the issue raised. But while we are on the subject of having to do special things to support location hiding (which is what I think you are talking about), I'd like to point out that the centroid of the intersection idea is a special case needed only for location hiding and imposes an implementation burden on everybody else, even though they are doing location hiding. While centroid calculations on polygons may be something we end up needing to do, the normal case would not seek to avoid holes - or jurisdictions contained entirely in another jurisdiction. However, for location hiding, the centroid calculation would have to compensate for any holes to avoid misrouting the call. >> Issue 1-3 UAs must now be forbidden from conveying dereferenced >> location information. > > I don't see why. LocationConveyance supports multiple locations. For the normal case, there is nothing wrong with an end point dereferencing an LbyR and passing along the location information as a value. With location-hiding, you don't want an endpoint doing this because the coarse location may have compensated for a hole and its centroid might not be accurate enough for dispatch. > >> Issue 1-4 The semantic difference regarding authorization/ >> nonauthorization of location information is lost, making it >> difficult for UAs to know if they truly are not authorized to get >> true location information. This introduces ambiquity, which should >> be avoided for emergency situations. > > I can't parse this. There is little ambiguity in a 403 Forbidden > HTTP response, but in any event, the UA without credentials would > get location, not a refusal, just not with the same accuracy. That's exactly the point. If an endpoint isn't authorized to get location, then it should be told so. It should not be led to believe that it has location as accurate as is possible. The semantics are being overloaded in an ambiguous way. >> Issue 2a-2 The work around LoST discovery needs to be completed. >> This is not specific to location hiding. > > The issue is that LoST discovery will likely return multiple > servers. I had earlier pointed out at least three plausible > operators (ISP, VSP, general public service), provided by several > different configuration mechanisms. The UA has to use the right > one, as things will fail otherwise. I don't understand your point. Do you believe codifying the preference order is difficult and too burdensome to define? > Also, from an operator perspective, here the landline ISP has to > operate a LoST resolver, instead of dumb "return fixed location" > server. Well, I would hope running a LoST resolver is not much more troublesome than running a DNS resolver. It really isn't that big of a deal. But the LIS cannot be dumb in the first place, as it must know about authorization policies, etc.. and know to provide fine location vs coarse location. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 07 14:43:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl8BQ-0007EU-Hu; Mon, 07 May 2007 14:43:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl8BO-0007EK-Qv for ecrit@ietf.org; Mon, 07 May 2007 14:43:38 -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 1Hl8BN-0003Ya-Ju for ecrit@ietf.org; Mon, 07 May 2007 14:43:38 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Mon, 07 May 2007 14:43:37 -0400 id 015880B4.463F7359.0000380E In-Reply-To: <259FCD67-0815-4DFD-9BEE-E48AE824BFBB@cs.columbia.edu> References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> <4991CDE0-BA87-42E5-BCEA-2A8ED6324FA1@cs.columbia.edu> <3D8F471D-84F5-412D-9BFC-26209827F3CD@hxr.us> <58F11B2F-0FE7-41FD-9938-3B560968942B@hxr.us> <1A8339C1-B5C4! ! ! ! -425F-A697-0F93AC93754A@cs.columbia.edu> <57D0B17F-E13B-4EA9-85C0-5803C02E9390@cs.columbia.edu> <259FCD67-0815-4DFD-9BEE-E48AE824BFBB@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <66AAE899-3287-4ACE-887D-1B918002E524@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Profiles (was: Consensus Call) - namespaces Date: Mon, 7 May 2007 14:43:35 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 On Apr 27, 2007, at 10:35 PM, Henning Schulzrinne wrote: > This concrete example is helpful. > > Since applications such as LoST don't typically do schema > validation, maybe it's more helpful to look at what an application > would actually do, such as using SAX and DOM. > > Clearly, the application only has a limited repertoire of XML tags > that it recognizes and then parses. It will presumably build up its > internal data structure from those elements. > > There are two cases: > > (1) Senders can only generate certain orderings of elements, such > as Point followed by civicAddress, even though the schema allows > any ordering. A 'profile' specifies this. > > (2) Any ordering permitted by the schema can appear in the XML > document. > > Doing (1) simplifies processing, since there are fewer elements > that can occur at any given time, but with an event-based or DOM- > based model, it doesn't seem to make a whole lot of difference. There was a leap in logic to "doesn't seem to make a whole lot of difference" that I don't understand. As far as ingesting the data in to data structures, yes. As far as recognition of the semantics, the server is still left to attempting to figure out what profile the sender is using without any hints. Given your logic, you could argue that XML namespace declarations are completed unneeded as applications should be able to know that when tag always precedes tag , they are dealing with tags from the http://example.com/foobar namespace. > We obviously do want to restrict the GML elements that can occur in > the XML sent, but that's a standardization issue, not a labeling > issue. Thus, I'm all in favor of defining profiles for the sender. We are in agreement here. > I just don't see how a profile label (beyond the namespace > indications) would simplify the processing or improve error > processing. Because, it would allow the sender to tell the server which profile it was sending. Since neither of us seem to be advocating XML validation in this case, I be happy to compromise and say that senders do not have to include the profile identifier if they don't know it. Is that workable? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 07 20:11:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlDIa-0004LR-1s; Mon, 07 May 2007 20:11:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlDIY-0004Kk-T4; Mon, 07 May 2007 20:11:22 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlDIU-0007ij-IG; Mon, 07 May 2007 20:11:22 -0400 X-SEF-Processed: 5_0_0_910__2007_05_07_19_18_12 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 07 May 2007 19:18:12 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 May 2007 19:11:13 -0500 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] Circuit ID Date: Mon, 7 May 2007 19:11:12 -0500 Message-ID: In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA03D0E215@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Circuit ID Thread-Index: AceHFQyqZlnQ5g2ETgCZ331d4v3yGgAN65nwADJEieACO+H1sA== From: "Winterbottom, James" To: "Stark, Barbara" , "Clive D.W. Feather" , "Henning Schulzrinne" X-OriginalArrivalTime: 08 May 2007 00:11:13.0906 (UTC) FILETIME=[63D42520:01C79105] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: GEOPRIV , 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 DSL Forum document TR-101 describes this in detail I think.=0D=0A=0D=0AChee= rs=0D=0AJames=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Stark, B= arbara [mailto:Barbara.Stark@BellSouth.com]=0D=0A> Sent: Friday, 27 April 2= 007 1:20 AM=0D=0A> To: Stark, Barbara; Clive D.W. Feather; Henning Schulzri= nne=0D=0A> Cc: GEOPRIV; ECRIT=0D=0A> Subject: RE: [Ecrit] Circuit ID=0D=0A>= =20=0D=0A> It turns out I was wrong about the Circuit ID and RADIUS. I just= can't=0D=0A> seem to keep up with the architecture changes going on.=0D=0A= > Yes, in newer equipment, the Access Node (DSLAM) adds the Circuit ID=0D=0A= to=0D=0A> both DHCP and PPP protocols. This is copied into the message sent= to=0D=0A> RADIUS.=0D=0A> Barbara=0D=0A>=20=0D=0A> -----Original Message---= --=0D=0A> From: Stark, Barbara=0D=0A> Sent: Wednesday, April 25, 2007 11:28= AM=0D=0A> To: Clive D.W. Feather; Henning Schulzrinne=0D=0A> Cc: GEOPRIV; = ECRIT=0D=0A> Subject: RE: [Ecrit] Circuit ID=0D=0A>=20=0D=0A> Circuit IDs h= ave nothing to do with RADIUS, that I'm aware of.=0D=0A> "Circuit ID" forma= t is defined by whatever system an access company=0D=0Auses=0D=0A> to manag= e its inventory of circuits. The most common such system in=0D=0Athe=0D=0A>= US is TIRKS(R), which is now developed by Telcordia. It was initially=0D=0A= > developed by AT&T Bell Labs in the late 1970's. Fortunately, it has=0D=0A= > managed to evolve a bit since then. Most of the baby Bells continue to=0D= =0A> use it, I think.=0D=0A> There's a really short Wikipedia description o= f TIRKS at=0D=0A> http://en.wikipedia.org/wiki/TIRKS=0D=0A> In short, a Cir= cuit ID uniquely identifies a circuit within an access=0D=0A> provider's op= erations systems. Many different types of circuits exist=0D=0A> (POTS, T1, = DS3, SONET, etc.). Different types use different formats.=0D=0A> Barbara=0D= =0A>=20=0D=0A> -----Original Message-----=0D=0A> From: Clive D.W. Feather [= mailto:clive@demon.net]=0D=0A> Sent: Wednesday, April 25, 2007 4:37 AM=0D=0A= > To: Henning Schulzrinne=0D=0A> Cc: Stark, Barbara; GEOPRIV; ECRIT=0D=0A> = Subject: Re: [Ecrit] Circuit ID=0D=0A>=20=0D=0A> Henning Schulzrinne said:=0D= =0A> > Just out of curiosity, what does a circuit ID look like=3F Is that t= he=0D=0A> > NAS identifier used in RADIUS or where is it visible=3F=0D=0A> =0D= =0A> In the UK it's not currently standardised, though we're looking at it.=0D= =0AI=0D=0A> would *expect* it to end up something like BT-EA12345678 or=0D=0A= > 001-EA12345678 where the first part identifies the circuit owner=0D=0A(ei= ther=0D=0A> a short name or a=0D=0A> CUPID) and the second half is decided = by the provider; BT appear to=0D=0Ause=0D=0A> a two letter region code foll= owed by an 8 digit number).=0D=0A>=20=0D=0A> >> Actually, given requirement= s for "naked" DSL, without an underlying=0D=0A> >> POTS phone number, we're= moving to "Circuit ID".=0D=0A>=20=0D=0A> That's not the only scenario - th= e UK is looking at an arrangement=0D=0A> whereby one telco (Openreach, part= of BT) provides the circuit and=0D=0A> another telco provides the call ser= ver and thus the number; Openreach=0D=0A> and BT will have no visibility of= the number - if any - allocated to=0D=0Athe=0D=0A> line.=0D=0A>=20=0D=0A> = --=0D=0A> Clive D.W. Feather | Work: | Tel: +44 20= 8495=0D=0A> 6138=0D=0A> Internet Expert | Home: |= Fax: +44 870 051=0D=0A> 9937=0D=0A> Demon Internet | WWW: http://w= ww.davros.org | Mobile: +44 7973=0D=0A> 377646=0D=0A> THUS plc |= |=0D=0A>=20=0D=0A> *****=0D=0A>=20=0D=0A> The i= nformation transmitted is intended only for the person or entity=0D=0Ato=0D= =0A> which it is addressed and may contain confidential, proprietary,=0D=0A= and/or=0D=0A> privileged material. Any review, retransmission, disseminatio= n or=0D=0Aother=0D=0A> use of, or taking of any action in reliance upon thi= s information by=0D=0A> persons or entities other than the intended recipie= nt is prohibited.=0D=0AIf=0D=0A> you received this in error, please contact= the sender and delete the=0D=0A> material from all computers. GA623=0D=0A>= =20=0D=0A>=20=0D=0A>=20=0D=0A> ____________________________________________= ___=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https://www1.iet= f.org/mailman/listinfo/ecrit=0D=0A>=20=0D=0A> _____________________________= __________________=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> h= ttps://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A--------------------= ---------------------------------------------------------------------------= -=0D=0AThis message is for the designated recipient only and may=0D=0Aconta= in privileged, proprietary, or otherwise private information. =20=0D=0AIf y= ou have received it in error, please notify the sender=0D=0Aimmediately and= delete the original. Any unauthorized use of=0D=0Athis email is prohibite= d.=0D=0A-------------------------------------------------------------------= -----------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 07 23:08:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlG4I-0000Pi-IL; Mon, 07 May 2007 23:08:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlG4H-0000Pa-22 for ecrit@ietf.org; Mon, 07 May 2007 23:08:49 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlG4G-0001OH-ON for ecrit@ietf.org; Mon, 07 May 2007 23:08:49 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l4838jK1015019 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 7 May 2007 23:08:46 -0400 (EDT) In-Reply-To: <66AAE899-3287-4ACE-887D-1B918002E524@hxr.us> References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> <4991CDE0-BA87-42E5-BCEA-2A8ED6324FA1@cs.columbia.edu> <3D8F471D-84F5-412D-9BFC-26209827F3CD@hxr.us> <58F11B2F-0FE7-41FD-9938-3B560968942B@hxr.us> <1A8339C1-B5C4! ! ! ! ! ! -425F-A697-0F93AC93754A@cs.columbia.edu> <57D0B17F-E13B-4EA9-85C0-5803C02E9390@cs.columbia.edu> <259FCD67-0815-4DFD-9BEE-E48AE824BFBB@cs.columbia.edu> <66AAE899-3287-4ACE-887D-1B918002E524@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <53016ABB-7A94-4B31-915B-33A4289F6B05@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Profiles (was: Consensus Call) - namespaces Date: Mon, 7 May 2007 23:08:43 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 >> (1) Senders can only generate certain orderings of elements, such >> as Point followed by civicAddress, even though the schema allows >> any ordering. A 'profile' specifies this. >> >> (2) Any ordering permitted by the schema can appear in the XML >> document. >> >> Doing (1) simplifies processing, since there are fewer elements >> that can occur at any given time, but with an event-based or DOM- >> based model, it doesn't seem to make a whole lot of difference. > > There was a leap in logic to "doesn't seem to make a whole lot of > difference" that I don't understand. As far as ingesting the data > in to data structures, yes. As far as recognition of the > semantics, the server is still left to attempting to figure out > what profile the sender is using without any hints. I don't see what hints you can offer in this particular case. As far as I know, we have not attributed any semantics to the ordering of the elements. In general, I think it would be a bad idea to do so, given that the schema considers both orderings equivalent. > > Given your logic, you could argue that XML namespace declarations > are completed unneeded as applications should be able to know that > when tag always precedes tag , they are dealing with > tags from the http://example.com/foobar namespace. I'm making no such leap. The namespace defines what elements are legal and is required for validation. (I'm guessing I agree with you that most XML parsers ignore the namespace declaration, but that doesn't mean that they are unnecessary. After all, we want to *allow* validation at the receiver, even if we don't require it and even if most systems won't perform it except maybe in debug mode.) > >> I just don't see how a profile label (beyond the namespace >> indications) would simplify the processing or improve error >> processing. > > Because, it would allow the sender to tell the server which profile > it was sending. Since neither of us seem to be advocating XML > validation in this case, I be happy to compromise and say that > senders do not have to include the profile identifier if they don't > know it. Is that workable? That's certainly a step in the right direction and probably the minimum we need to do. However, including the label simply adds another error condition that needs to be tested for. Now, the recipient has to verify whether profile and content agree. The most likely consequence is that most receivers will simply ignore the profile label. Such 'latent' error conditions are not good, as a mislabeling sender will likely not get an error message except from some small subset of hyper-sensitive implementations - which may then only occur during an emergency, when it's too late to fix. Or are you suggesting that the receiver treat this only as a hint and ignore the label if it contradicts the XML? (We have a version of this problem today. IE and maybe other browsers will ignore the Content-Type header and render based on inspecting the content, since many webservers get the Content-Type wrong. I'm not advocating this as good programming practice, but it shows the likely outcome.) > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 08 15:23:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlVHT-00036J-9D; Tue, 08 May 2007 15:23:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlVHS-00036E-Jr for ecrit@ietf.org; Tue, 08 May 2007 15:23:26 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlVHS-0004xP-94 for ecrit@ietf.org; Tue, 08 May 2007 15:23:26 -0400 Received: from [160.39.246.25] (dyn-wireless-246-25.dyn.columbia.edu [160.39.246.25]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l48JNIqf009929 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 8 May 2007 15:23:19 -0400 (EDT) In-Reply-To: References: <463B6EAB.7060604@bbn.com> <31D7CCEF-4BDA-489F-B0BA-B61C66253CA6@hxr.us> <90ED6EE1-E045-4A40-8B63-1D87C0017217@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8EF75271-21F5-4A58-B6DA-9BE6970576BC@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Location hiding: Consensus? Date: Tue, 8 May 2007 15:25:12 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 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 >> >> We are not in the business of creating business opportunities for >> carriers at the expense of others. As long as our main 'customers' >> don't object, it's not our role to make life difficult and less >> debugable for emergency services. Given that GeoMind and others >> are giving away rough location information, the value of such >> information is in doubt in any event. > > What!? I don't understand your response and can't seem how it is > even directly relevant to the issue raised. > Maybe lowering the !? volume would be helpful. You had written about the commercial usefulness of country-level location information as a reason that we should support hiding it. This is a business model issue, in my view. Protecting commercial value is certainly not a technical requirement. > But while we are on the subject of having to do special things to > support location hiding (which is what I think you are talking > about), I'd like to point out that the centroid of the intersection > idea is a special case needed only for location hiding and imposes > an implementation burden on everybody else, even though they are > doing location hiding. Not quite. The same functionality will be needed in the future when we have to support location determination techniques that don't return points, but rather uncertainty polygons. Earlier in the profile discussion, we had talked about deferring this for now, so we're simply forced to face this a bit earlier than planned. > > While centroid calculations on polygons may be something we end up > needing to do, the normal case would not seek to avoid holes - or > jurisdictions contained entirely in another jurisdiction. However, > for location hiding, the centroid calculation would have to > compensate for any holes to avoid misrouting the call. However, that pothole-avoidance computation only needs to be done by the LIS, not the LoST server. Thus, the computational and complexity burden is imposed on the party that is restricting access to location information, which seems to me to be the right trade-off. > >>> Issue 1-3 UAs must now be forbidden from conveying dereferenced >>> location information. >> >> I don't see why. LocationConveyance supports multiple locations. > > For the normal case, there is nothing wrong with an end point > dereferencing an LbyR and passing along the location information as > a value. With location-hiding, you don't want an endpoint doing > this because the coarse location may have compensated for a hole > and its centroid might not be accurate enough for dispatch. I think this is an instance of a general problem, namely that the SIP INVITE may contain multiple locations with different characteristics. For example, it could contain a (fixed) value and a reference that's updated based on movement of the caller. In that case, you also have a location (value) that may no longer be suitable for dispatch, and another (reference) which is preferable, i.e., exactly the same behavior. We had also earlier heard of the example where, due to the delay in location determination, the initial call contains a cell/sector value, with a reference that will (hopefully) be more accurate by the time first responders are dispatched. Thus, this isn't a new or hiding-unique problem, as annoying as it can be. (In general, I tend to think of the location hiding problem as being an artificially-created version of the two-stage cell/ sector, followed by AGPS, location determination in cellular systems.) > >> >>> Issue 1-4 The semantic difference regarding authorization/ >>> nonauthorization of location information is lost, making it >>> difficult for UAs to know if they truly are not authorized to get >>> true location information. This introduces ambiquity, which >>> should be avoided for emergency situations. >> >> I can't parse this. There is little ambiguity in a 403 Forbidden >> HTTP response, but in any event, the UA without credentials would >> get location, not a refusal, just not with the same accuracy. > > That's exactly the point. If an endpoint isn't authorized to get > location, then it should be told so. It should not be led to > believe that it has location as accurate as is possible. The > semantics are being overloaded in an ambiguous way. I'd be the last to defend location hiding as desirable, but I fail to see why providing no location at all is preferable to providing some location. As noted on the Wiki, having some location at least allows the end system/user to detect gross errors before placing a call. > >>> Issue 2a-2 The work around LoST discovery needs to be completed. >>> This is not specific to location hiding. >> >> The issue is that LoST discovery will likely return multiple >> servers. I had earlier pointed out at least three plausible >> operators (ISP, VSP, general public service), provided by several >> different configuration mechanisms. The UA has to use the right >> one, as things will fail otherwise. > > I don't understand your point. Do you believe codifying the > preference order is difficult and too burdensome to define? Yes, because the LIS won't know what other location sources are available to the end user and what services it wants to use. Would this special LoST resolver be available for other lookups, e.g., generated from GPS data? Would it support non-emergency services? > >> Also, from an operator perspective, here the landline ISP has to >> operate a LoST resolver, instead of dumb "return fixed location" >> server. > > Well, I would hope running a LoST resolver is not much more > troublesome than running a DNS resolver. It really isn't that big > of a deal. But the LIS cannot be dumb in the first place, as it > must know about authorization policies, etc.. and know to provide > fine location vs coarse location. I agree that this is not a major hurdle, but if I recall correctly, some of the operators triggering this discussion have expressed a strong preference for as little additional infrastructure as possible. The location access issue is relatively easy, as existing Apache modules can handle this. In many cases, IP address-based authorization is all that's needed, unless the operator is extremely paranoid. I think we're starting to exhaust this topic. It's clear that several solutions can be made to work, with different trade-offs in terms of protocol linkages, protocol changes necessary only for location hiding and infrastructure deployment, as well as the amount of debugging information available to end users. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 09 02:52:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlg25-0007PQ-HA; Wed, 09 May 2007 02:52:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlg24-0007Ld-Pg for ecrit@ietf.org; Wed, 09 May 2007 02:52:16 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlg23-0007HD-GN for ecrit@ietf.org; Wed, 09 May 2007 02:52:16 -0400 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l496prGv031671; Wed, 9 May 2007 00:51:54 -0600 Message-ID: <46416F89.4010606@ntt-at.com> Date: Tue, 08 May 2007 23:51:53 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Subject: [Ecrit] LoST returning location used?? 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 I might have overlooked something completely but while I was reviewing the framework document the following question came up. The framework document expects some sort of flagging on the location to indicate which location was used to do location based routing (LoST & non-LoST) when there are multiple location information in the message. According to the LoST-05, the client can insert multiple location information but which location was used for the actual resolution is not returned to the client. One may guess or sometime clearly find out which location was used, simply analyzing the "ServiceBoundary" but according to the debate going on right now it doesn't seem so simple after all. If the client can't tell which location was actually used for routing, how would the client, let's say a proxy using the "used-for-routing" parameter indicate which location was actually used for routing the call. The framework also expects the entity on the signaling path acting as a LoST client to use the same location information flagged with "used-for-routing", would it restrict the LoST client to include only the flagged location information for LoST query once it's flagged using "used-for-routing"?? Regards Shida _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 09 03:26:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlgZD-0002bU-4H; Wed, 09 May 2007 03:26:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlgZC-0002aZ-3Y for ecrit@ietf.org; Wed, 09 May 2007 03:26:30 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlgZB-0007m2-NH for ecrit@ietf.org; Wed, 09 May 2007 03:26:30 -0400 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l497QRej014177 for ; Wed, 9 May 2007 01:26:28 -0600 Message-ID: <464177A2.9040104@ntt-at.com> Date: Wed, 09 May 2007 00:26:26 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Subject: [Ecrit] Review: draft-ietf-ecrit-framework-01.txt 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 Draft: draft-ietf-ecrit-framework-01 Reviewer: Shida Schubert Review Date: 2007.05.02 Summary: ---------------------------------------- - Overall I think it's a well written draft giving a really good overview of how everything interacts. - The draft needs some overhaul reflecting all the recent discussions in ECRIT, GEOPRIV and SIP WG regarding location hiding, emergency call verification, L7 LCP etc. - The terminology needs to be aligned with the current version of requirement/LoST draft. Technical Comments: ---------------------------------------- T1: Chapter 3, 1st paragraph, 1st sentence. - Although we haven't come to a conclusion on how emergency call is distinguished, I believe the currently many see it as either by a emergency dialstring or by service URN. - The current text seems to allude that dialstring is necessary to place the (Emergency) service URN. T2: Chapter 4, 3rd paragraph, 3rd sentence. - I don't think the following text is true. "It should be noted that the endpoint would not normally supply location unless it understood the call to be an emergency call." > I see this to be somewhat misleading. It's true in case of an emergency if UA supports location, it should without a doubt include location information but the statement above is definitely not correct. If the text is merely a note, it may be good to simply remove the text. T3. Chapter 5.8, 1st paragraph, 1st sentence. - Although not a normative text, "Location must be validated" seems a bit too strong. I don't have a strong feeling for this but I prefer something like a should rather than a must.. Clarification Needed: ---------------------------------------- C1: Chapter 2, last 2 paragraphs. - It's unsure what "this document", "this draft" is pointing at. From the context it seems to be pointing at the phone-bcp but it's unclear. C2: Chapter2, last 2 paragraphs. - If these paragraphs are indeed about phone-bcp then the last sentence is incorrect. As far as I understand phone-bcp will have recommended behavior of LoST, proxy(outbound and others) and UAs. C3: Chapter 3, 3rd paragraph, 3rd sentence. - The reason why registration is necessary is not mentioned here. If it's for call-back purpose I think it should be mentioned as well. What about non-authorized device that can't REGISTER? C4: Chapter 5.3, 3rd paragraph, 2nd sentence. - It's unclear what policy you mean by "To facilitate such policy decision". C5: Chapter 5.3, 3rd paragraph, 3rd sentence. - What do you mean by the generator of the location information? Is generator same as whatever goes into the in PIDF-LO? Editorial Comments: ---------------------------------------- E1: Chapter 3, 1st paragraph, 1st sentence. - Although we haven't come to a conclusion on how emergency call is distinguished, I believe the currently many see it as either by a emergency dialstring or by service URN. - The current text seems to allude that dialstring is necessary to place the (Emergency) service URN. E2: Chapter 3, 2nd paragraph, 3rd bullet, last sentence. - Term LoST dip is used although one can assume what it means, it's not the term used in LoST document thus should probably use the proper term used in LoST document. (Same term is used in section 6, 2nd last paragraph) E3: Chapter 3, 2nd paragraph, 4th bullet, 1st sentence. - Service URN is not mentioned as the parameter used to resolve PSAP URIs. OLD: LoST Server - Processes the LoST request for Location to PSAP-URI Mapping function, either for an initial request from a UA, or an in-call routing by the Proxy server in the originating network, or possibly by an ESRP. NEW: LoST Server - Processes the LoST request for Location + Service URN to PSAP-URI Mapping function, either for an initial request from a UA, or an in-call routing by the Proxy server in the originating network, or possibly by an ESRP. E4: Chapter 3, 3rd paragraph, 2nd sentence. - Acronym LCP is used without any introduction to it. The following text change should be made where location configuration protocol is mentioned. OLD: Generally, Alice's UA either has location configured manually, has an integral location measurement mechanism, or it runs a location configuration protocol to obtain location from the access (broadband) network. NEW: Generally, Alice's UA either has location configured manually, has an integral location measurement mechanism, or it runs a location configuration protocol (LCP) to obtain location from the access (broadband) network. E5: Chapter 3, 3rd paragraph, 4th sentence. - The reason to obtain PSAP URI prior to making an emergency call is to have something to use in case of LoST failure at emergency time and also for testing. OLD: Next, her UA will perform an initial LoST Location-to-PSAP SIP(S)-URI query to learn a URI, for use if the Lost Query fails during an emergency call. NEW: Next, her UA will perform an initial LoST Location-to-PSAP SIP(S)-URI query to learn a URI, for use if the Lost Query fails during an emergency call or to use it to test emergency call. E6: Chapter 5.3, 4th paragraph, last sentence. - The reference to location conveyance is currently to that of LoST. Needs to be fixed. E7: Chapter 5.5, 3rd paragraph, last sentence. - The reference is made to LoST which should be changed to Phone-BCP. E8: Chapter 5.8. - Although not a normative text, "Location must be validated" seems a bit too strong. E9: Chapter 10, 2nd paragraph, 1st sentence. - redundant "of". I hope it helps. Thanks & Regards -- Shida Sven Schubert shida@ntt-at.com PHONE: (604) 762-5606 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 09 09:35:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlmJy-0001fC-9K; Wed, 09 May 2007 09:35:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlmJw-0001d6-QG for ecrit@ietf.org; Wed, 09 May 2007 09:35:08 -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 1HlmI7-0007Gw-U5 for ecrit@ietf.org; Wed, 09 May 2007 09:33:17 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 09 May 2007 09:33:15 -0400 id 015881AA.4641CD9B.000067EB In-Reply-To: <53016ABB-7A94-4B31-915B-33A4289F6B05@cs.columbia.edu> References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> <4991CDE0-BA87-42E5-BCEA-2A8ED6324FA1@cs.columbia.edu> <3D8F471D-84F5-412D-9BFC-26209827F3CD@hxr.us> <58F11B2F-0FE7-41FD-9938-3B560968942B@hxr.us> <1A8339C1-B5C4! ! ! ! ! ! -425F-A697-0F93AC93754A@cs.columbia.edu> <57D0B17F-E13B-4EA9-85C0-5803C02E9390@cs.columbia.edu> <259FCD67-0815-4DFD-9BEE-E48AE824BFBB@cs.columbia.edu> <66AAE899-3287-4ACE-887D-1B918002E524@hxr.us> <53016ABB-7A94-4B31-915B-33A4289F6B05@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Profiles (was: Consensus Call) - namespaces Date: Wed, 9 May 2007 09:33:10 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 On May 7, 2007, at 11:08 PM, Henning Schulzrinne wrote: > I don't see what hints you can offer in this particular case. As > far as I know, we have not attributed any semantics to the ordering > of the elements. In general, I think it would be a bad idea to do > so, given that the schema considers both orderings equivalent. Consider location profiles that are not yet defined. Which one is this? -34.407 150.883 -34.409 150.879 850.24 Of course, if you are suggesting that future profiles the glue multiple elements together such as this would need to define their own schema to properly define them, then I consider that a fair design choice. That does mean that the current method of 3825 compound location defined in pdif-lo-profile would need a schema that wraps the gml and civicAddress. Also, why would the LoST server need to identify profiles then? It should use the same XML namespace mechanism. >> Because, it would allow the sender to tell the server which >> profile it was sending. Since neither of us seem to be advocating >> XML validation in this case, I be happy to compromise and say that >> senders do not have to include the profile identifier if they >> don't know it. Is that workable? > > That's certainly a step in the right direction and probably the > minimum we need to do. > > However, including the label simply adds another error condition > that needs to be tested for. Now, the recipient has to verify > whether profile and content agree. The most likely consequence is > that most receivers will simply ignore the profile label. Such > 'latent' error conditions are not good, as a mislabeling sender > will likely not get an error message except from some small subset > of hyper-sensitive implementations - which may then only occur > during an emergency, when it's too late to fix. There is no need to add another error condition. Either the server knows what it is looking at or it doesn't. > Or are you suggesting that the receiver treat this only as a hint > and ignore the label if it contradicts the XML? Yes. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 09 10:07:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlmop-00061d-0p; Wed, 09 May 2007 10:07:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlmon-00061Y-0x for ecrit@ietf.org; Wed, 09 May 2007 10:07:01 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlmom-0007KR-Nv for ecrit@ietf.org; Wed, 09 May 2007 10:07:01 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 09 May 2007 10:07:00 -0400 id 015881AA.4641D584.00006F43 In-Reply-To: <8EF75271-21F5-4A58-B6DA-9BE6970576BC@cs.columbia.edu> References: <463B6EAB.7060604@bbn.com> <31D7CCEF-4BDA-489F-B0BA-B61C66253CA6@hxr.us> <90ED6EE1-E045-4A40-8B63-1D87C0017217@cs.columbia.edu> <8EF75271-21F5-4A58-B6DA-9BE6970576BC@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Location hiding: Consensus? Date: Wed, 9 May 2007 10:06:58 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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 On May 8, 2007, at 3:25 PM, Henning Schulzrinne wrote: > Maybe lowering the !? volume would be helpful. I didn't realize your sensitivity to punctuation. > You had written about the commercial usefulness of country-level > location information as a reason that we should support hiding it. > This is a business model issue, in my view. Protecting commercial > value is certainly not a technical requirement. So what is the reason for supporting location hiding? Otherwise, you seem to be arguing that your view location hiding is correct and cannot be questioned. I have simply pointed out that location hiding should hide all location information and that there are good reasons for it. I certainly would like to hear your reasons why my arguments should not be considered. >> While centroid calculations on polygons may be something we end up >> needing to do, the normal case would not seek to avoid holes - or >> jurisdictions contained entirely in another jurisdiction. >> However, for location hiding, the centroid calculation would have >> to compensate for any holes to avoid misrouting the call. > > However, that pothole-avoidance computation only needs to be done > by the LIS, not the LoST server. Thus, the computational and > complexity burden is imposed on the party that is restricting > access to location information, which seems to me to be the right > trade-off. I don't think calling jurisdictions contained within other jurisdictions "potholes" is a good idea. But the hole-avoidance computation needs to be done by the validating seeker, which is the VSP. And it needs to know when it is to do the hole-avoidance vs. just a normal polygon lookup. If that is not the case, perhaps I misunderstanding how this is to work. Could you describe the inputs, computations, and outputs at every step in the process? >>>> Issue 1-3 UAs must now be forbidden from conveying dereferenced >>>> location information. >>> >>> I don't see why. LocationConveyance supports multiple locations. >> >> For the normal case, there is nothing wrong with an end point >> dereferencing an LbyR and passing along the location information >> as a value. With location-hiding, you don't want an endpoint >> doing this because the coarse location may have compensated for a >> hole and its centroid might not be accurate enough for dispatch. > > I think this is an instance of a general problem, namely that the > SIP INVITE may contain multiple locations with different > characteristics. For example, it could contain a (fixed) value and > a reference that's updated based on movement of the caller. In that > case, you also have a location (value) that may no longer be > suitable for dispatch, and another (reference) which is preferable, > i.e., exactly the same behavior. Perhaps it is my reading of the phone-bcp document. Steps 10, 11, & 12 in section 6.1 talk about what to do here. There are no steps that say "do not dereference an LbyR and use the result as an LbyV". Now that must be expressly disallowed, though your example above also provides a good reason to disallow it. > I'd be the last to defend location hiding as desirable, but I fail > to see why providing no location at all is preferable to providing > some location. As noted on the Wiki, having some location at least > allows the end system/user to detect gross errors before placing a > call. Well, I think it would be preferable to fully support location hiding rather than to only partially support it. But suggesting that end users will be able to know gross location errors is a bit of wishful thinking. For lat/long, I doubt most users would be able to know. As for civic, I always tend to get confused when I've driven into Montgomery Co., MD, when I'm in DC -- knowing the demarkation for various civic jurisdictions isn't something you can count on an end user understanding. >>>> Issue 2a-2 The work around LoST discovery needs to be completed. >>>> This is not specific to location hiding. >>> >>> The issue is that LoST discovery will likely return multiple >>> servers. I had earlier pointed out at least three plausible >>> operators (ISP, VSP, general public service), provided by several >>> different configuration mechanisms. The UA has to use the right >>> one, as things will fail otherwise. >> >> I don't understand your point. Do you believe codifying the >> preference order is difficult and too burdensome to define? > > Yes, because the LIS won't know what other location sources are > available to the end user and what services it wants to use. Would > this special LoST resolver be available for other lookups, e.g., > generated from GPS data? Would it support non-emergency services? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 09 10:19:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hln0m-0004hQ-K6; Wed, 09 May 2007 10:19:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hln0l-0004hL-L8 for ecrit@ietf.org; Wed, 09 May 2007 10:19:23 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hln0k-0001KM-EU for ecrit@ietf.org; Wed, 09 May 2007 10:19:23 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 09 May 2007 10:19:21 -0400 id 01588422.4641D869.00007188 In-Reply-To: <8EF75271-21F5-4A58-B6DA-9BE6970576BC@cs.columbia.edu> References: <463B6EAB.7060604@bbn.com> <31D7CCEF-4BDA-489F-B0BA-B61C66253CA6@hxr.us> <90ED6EE1-E045-4A40-8B63-1D87C0017217@cs.columbia.edu> <8EF75271-21F5-4A58-B6DA-9BE6970576BC@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <61C59536-D910-4638-B41C-3D87B0A377B0@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Location hiding: Consensus? Date: Wed, 9 May 2007 10:19:19 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 On May 8, 2007, at 3:25 PM, Henning Schulzrinne wrote: >>>> Issue 2a-2 The work around LoST discovery needs to be completed. >>>> This is not specific to location hiding. >>> >>> The issue is that LoST discovery will likely return multiple >>> servers. I had earlier pointed out at least three plausible >>> operators (ISP, VSP, general public service), provided by several >>> different configuration mechanisms. The UA has to use the right >>> one, as things will fail otherwise. >> >> I don't understand your point. Do you believe codifying the >> preference order is difficult and too burdensome to define? > > Yes, because the LIS won't know what other location sources are > available to the end user and what services it wants to use. Would > this special LoST resolver be available for other lookups, e.g., > generated from GPS data? Would it support non-emergency services? Well, since it would be a LoST resolver just like any other, then it could handle lookups from GPS data. As to which services it supports, that is up to the operator of the LoST resolver. If you are suggesting that they should not have to support the pizza- location service, then I would agree. But the issue of finding a LoST resolver for a particular service type is generic and not specific to location-hiding. I would think that for non-emergency services, the client would be preconfigured with LoST resolvers appropriate for those services. If that is incorrect and the ECRIT LoST discovery work, such as in draft-ietf-ecrit-dhc-lost-discovery, is to be to allow discovery of non-emergency LoST resolvers, then I cannot see how that would work. Methods of ECRIT LoST discovery should only be about discovering LoST resolvers capable of handling emergency services. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 09 11:01:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlnfi-0003zu-Mh; Wed, 09 May 2007 11:01:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlnfh-0003zn-P5 for ecrit@ietf.org; Wed, 09 May 2007 11:01:41 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlnff-0000Rq-8l for ecrit@ietf.org; Wed, 09 May 2007 11:01:41 -0400 Received: from [160.39.254.132] (dyn-160-39-254-132.dyn.columbia.edu [160.39.254.132]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l49F1U2a011939 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 9 May 2007 11:01:30 -0400 (EDT) In-Reply-To: References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> <4991CDE0-BA87-42E5-BCEA-2A8ED6324FA1@cs.columbia.edu> <3D8F471D-84F5-412D-9BFC-26209827F3CD@hxr.us> <58F11B2F-0FE7-41FD-9938-3B560968942B@hxr.us> <1A8339C1-B5C4! ! ! ! ! ! ! ! -425F-A697-0F93AC93754A@cs.columbia.edu> <57D0B17F-E13B-4EA9-85C0-5803C02E9390@cs.columbia.edu> <259FCD67-0815-4DFD-9BEE-E48AE824BFBB@cs.columbia.edu> <66AAE899-3287-4ACE-887D-1B918002E524@hxr.us> <53016ABB-7A94-4B31-915B-33A4289F6B05@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8DF70F3D-00D2-4D44-B40B-4E284E3527AC@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Profiles (was: Consensus Call) - namespaces Date: Wed, 9 May 2007 11:03:22 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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 On May 9, 2007, at 9:33 AM, Andrew Newton wrote: > > On May 7, 2007, at 11:08 PM, Henning Schulzrinne wrote: >> I don't see what hints you can offer in this particular case. As >> far as I know, we have not attributed any semantics to the >> ordering of the elements. In general, I think it would be a bad >> idea to do so, given that the schema considers both orderings >> equivalent. > > Consider location profiles that are not yet defined. Which one is > this? > Obviously, there's no way to tell. But I thought we earlier agreed that unknown GML would get no profile label. The important part is that the receiver can recognize the GML. If it doesn't recognize the combination of point and circle, it is going to have to throw in the towel, with or without a profile label. > > -34.407 150.883 > > > > > > Of course, if you are suggesting that future profiles the glue > multiple elements together such as this would need to define their > own schema to properly define them, then I consider that a fair > design choice. That does mean that the current method of 3825 > compound location defined in pdif-lo-profile would need a schema > that wraps the gml and civicAddress. > > Also, why would the LoST server need to identify profiles then? It > should use the same XML namespace mechanism. No, it should recognize it by the the combinations of elements that it supports. If it sees something it can't recognize, it has to return an error. The only question is whether it should ignore elements that it doesn't understand, as in ... .. Should it ignore the blob and just go with the point? The compound locations in draft-ietf-geopriv-pdif-lo-profile-07 have well-defined rules as to what should come first and what can be included, so I fail to see the problem. (Again, we do need to coordinate that whatever is legal in LIS, according to the phone-bcp or whatever other document, is also legal in LoST, to avoid problems. That, however, isn't fixed or affected by a profile indication.) > >> Or are you suggesting that the receiver treat this only as a hint >> and ignore the label if it contradicts the XML? > > Yes. > As long as we specify this as a 'MAY insert as a hint' and 'receiver MUST ignore if it contradicts the XML', I'm not too hung up about including it. The use seems limited, but harmless. > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 09 11:20:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlnyL-00061S-9V; Wed, 09 May 2007 11:20:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlnyK-00061N-KQ for ecrit@ietf.org; Wed, 09 May 2007 11:20:56 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlnyI-0004yG-9U for ecrit@ietf.org; Wed, 09 May 2007 11:20:56 -0400 Received: from [160.39.254.132] (dyn-160-39-254-132.dyn.columbia.edu [160.39.254.132]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l49FKc7k028500 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 9 May 2007 11:20:38 -0400 (EDT) In-Reply-To: References: <463B6EAB.7060604@bbn.com> <31D7CCEF-4BDA-489F-B0BA-B61C66253CA6@hxr.us> <90ED6EE1-E045-4A40-8B63-1D87C0017217@cs.columbia.edu> <8EF75271-21F5-4A58-B6DA-9BE6970576BC@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <27C1D446-6E38-4A48-8FFF-3F65EFBA104F@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Location hiding: Consensus? Date: Wed, 9 May 2007 11:22:31 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f 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 On May 9, 2007, at 10:06 AM, Andrew Newton wrote: > > So what is the reason for supporting location hiding? Otherwise, > you seem to be arguing that your view location hiding is correct > and cannot be questioned. I have simply pointed out that location > hiding should hide all location information and that there are good > reasons for it. I certainly would like to hear your reasons why my > arguments should not be considered. > Location hiding is not an ECRIT charter goal and is not in any of the current requirements documents. So far, the only actual user requirements are for partial location hiding. Thus, I see no reason to support something that no implementors seem to be asking for, but which makes the system more brittle, imposes, on end users, costs and complexity. Are you suggesting that, from a technical standpoint, hiding location from the end system is a good idea? We can continue to invent requirements, and continue to make the system more complex and less debuggable. I fail to see the value in that. >>> While centroid calculations on polygons may be something we end >>> up needing to do, the normal case would not seek to avoid holes - >>> or jurisdictions contained entirely in another jurisdiction. >>> However, for location hiding, the centroid calculation would have >>> to compensate for any holes to avoid misrouting the call. >> >> However, that pothole-avoidance computation only needs to be done >> by the LIS, not the LoST server. Thus, the computational and >> complexity burden is imposed on the party that is restricting >> access to location information, which seems to me to be the right >> trade-off. > > I don't think calling jurisdictions contained within other > jurisdictions "potholes" is a good idea. But the hole-avoidance > computation needs to be done by the validating seeker, which is the > VSP. And it needs to know when it is to do the hole-avoidance vs. > just a normal polygon lookup. Unfortunately, in your model, the VSP would have no way to do any validation at all, since it is not operating a trusted LoST server, according to our 'no business relationship' requirement and thus can't resolve the reference. Thus, your model actually fails to support the validation requirements. That's certainly good to note. > > If that is not the case, perhaps I misunderstanding how this is to > work. Could you describe the inputs, computations, and outputs at > every step in the process? > I'm using Brian's variation of my proposal. The LIS computes, based on its querying of LoST, a geometric shape such as a polygon or circle whose centroid/center lands in the right PSAP and includes the current location of the client, presumably somewhere other than in the center. The VSP does exactly the same computation, again taking the center of the circle to do the lookup. Thus, it performs no special operation and is not concerned with holes in service areas at all. If the PSAP is a convex polygon, there's no need for the LIS computation, but the verifying VSP doesn't care one way or the other. > >>>>> Issue 1-3 UAs must now be forbidden from conveying dereferenced >>>>> location information. >>>> >>>> I don't see why. LocationConveyance supports multiple locations. >>> >>> For the normal case, there is nothing wrong with an end point >>> dereferencing an LbyR and passing along the location information >>> as a value. With location-hiding, you don't want an endpoint >>> doing this because the coarse location may have compensated for a >>> hole and its centroid might not be accurate enough for dispatch. >> >> I think this is an instance of a general problem, namely that the >> SIP INVITE may contain multiple locations with different >> characteristics. For example, it could contain a (fixed) value and >> a reference that's updated based on movement of the caller. In >> that case, you also have a location (value) that may no longer be >> suitable for dispatch, and another (reference) which is >> preferable, i.e., exactly the same behavior. > > Perhaps it is my reading of the phone-bcp document. Steps 10, 11, > & 12 in section 6.1 talk about what to do here. There are no steps > that say "do not dereference an LbyR and use the result as an > LbyV". Now that must be expressly disallowed, though your example > above also provides a good reason to disallow it. I suspect clarifying text is in order here. > >> I'd be the last to defend location hiding as desirable, but I fail >> to see why providing no location at all is preferable to providing >> some location. As noted on the Wiki, having some location at least >> allows the end system/user to detect gross errors before placing a >> call. > > Well, I think it would be preferable to fully support location > hiding rather than to only partially support it. But suggesting > that end users will be able to know gross location errors is a bit > of wishful thinking. For lat/long, I doubt most users would be > able to know. As for civic, I always tend to get confused when > I've driven into Montgomery Co., MD, when I'm in DC -- knowing the > demarkation for various civic jurisdictions isn't something you can > count on an end user understanding. Civic addresses are primarily of interest for the residential case, and I suspect most people know their street address enough to recognize that they've been placed in the wrong town or county. Given the availability of Google Maps, I don't see much of a problem with visualizing that location on such a map. I'm not claiming that everyone will do this, but that doesn't make it useless. Discovering some mistakes ahead of time seems to beat discovering none. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 09 19:10:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlvIy-0006Vx-0N; Wed, 09 May 2007 19:10:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlvIw-0006Vs-9m for ecrit@ietf.org; Wed, 09 May 2007 19:10:42 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlvIv-0006IA-0R for ecrit@ietf.org; Wed, 09 May 2007 19:10:42 -0400 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l49NAZ1b020978; Wed, 9 May 2007 17:10:37 -0600 Message-ID: <464254EB.1040205@ntt-at.com> Date: Wed, 09 May 2007 16:10:35 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ECRIT , Henning Schulzrinne Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Subject: [Ecrit] Review: draft-ietf-ecrit-mapping-arch-01.txt 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 Draft: draft-ietf-ecrit-mapping-arch-01 Reviewer: Shida Schubert Review Date: 2007.05.09 Summary: ---------------------------------------- - The draft looks really really good and solid and very informative indeed. I think the draft is ready for WGLC if the draft was a stand alone draft, but raises some questions on its value when I view it as a draft providing overall picture for how mapping works. It may be simply because of my ignorance, but I had a really hard time trying to map some of the logical entity to real world deployment introduced in this draft such as forest guide. It would be good to expand the text a bit to show for example what entity would serve forest guide and what logical entity LoST server generally serves etc. Technical Comments: ---------------------------------------- T1: Section 3, seeker. - Description of the seeker seems to contradict what's mentioned in the section 5. In section 3, it is clearly stated that skeeker may cache mapping result for its own use and not provide any mapping service to others, yet section 5 mentions about outbound proxy caching the mapping result to provide its user.. How would the outbound proxy provide the caching? I am assuming it is when it sees LoST query from its user, wouldn't it be providing mapping service once it's responding to a LoST query? Editorial Comments: ---------------------------------------- E1: Chapter 3. - resolver is defined twice. I hope it helps. Thanks & Regards -- Shida Sven Schubert shida@ntt-at.com PHONE: (604) 762-5606 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 09 21:31:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlxVD-0004WL-W4; Wed, 09 May 2007 21:31:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlxVC-0004WD-5r for ecrit@ietf.org; Wed, 09 May 2007 21:31:30 -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 1HlxVA-00088f-Ui for ecrit@ietf.org; Wed, 09 May 2007 21:31:30 -0400 Received: from [10.0.1.110] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 09 May 2007 21:31:28 -0400 id 0158837D.464275F0.00006E5D In-Reply-To: <27C1D446-6E38-4A48-8FFF-3F65EFBA104F@cs.columbia.edu> References: <463B6EAB.7060604@bbn.com> <31D7CCEF-4BDA-489F-B0BA-B61C66253CA6@hxr.us> <90ED6EE1-E045-4A40-8B63-1D87C0017217@cs.columbia.edu> <8EF75271-21F5-4A58-B6DA-9BE6970576BC@cs.columbia.edu> <27C1D446-6E38-4A48-8FFF-3F65EFBA104F@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Location hiding: Consensus? Date: Wed, 9 May 2007 21:31:23 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 On May 9, 2007, at 11:22 AM, Henning Schulzrinne wrote: > Are you suggesting that, from a technical standpoint, hiding > location from the end system is a good idea? I think you misunderstood my point. Simply put, if you are going through the trouble to support location hiding, you should support it fully and not partially. > Unfortunately, in your model, the VSP would have no way to do any > validation at all, since it is not operating a trusted LoST server, > according to our 'no business relationship' requirement and thus > can't resolve the reference. Thus, your model actually fails to > support the validation requirements. That's certainly good to note. Hmmm... yet in your model, the PSAP is somehow known as a trusted entity when dereferencing location. In whatever way that occurs, which has not been explained, the VSP can also use that trust relationship to determine if it is sending calls to a PSAP. There is another issue with the validation step. Taking Brian's now- infamous VSP in Sierra Leone, how can you be assured that the LoST tree used by the VSP is capable of traversing to the LoST tree used by the LIS? > I'm using Brian's variation of my proposal. The LIS computes, based > on its querying of LoST, a geometric shape such as a polygon or > circle whose centroid/center lands in the right PSAP and includes > the current location of the client, presumably somewhere other than > in the center. > > The VSP does exactly the same computation, again taking the center > of the circle to do the lookup. Thus, it performs no special > operation and is not concerned with holes in service areas at all. Since the computation is the same, why not just send the point that is the centroid? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 09 21:50:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlxnP-00076y-MY; Wed, 09 May 2007 21:50:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlxnO-00073I-5Y for ecrit@ietf.org; Wed, 09 May 2007 21:50:18 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlxnM-0003Ix-Te for ecrit@ietf.org; Wed, 09 May 2007 21:50:18 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l4A1o9Fg017074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 9 May 2007 21:50:15 -0400 (EDT) In-Reply-To: References: <463B6EAB.7060604@bbn.com> <31D7CCEF-4BDA-489F-B0BA-B61C66253CA6@hxr.us> <90ED6EE1-E045-4A40-8B63-1D87C0017217@cs.columbia.edu> <8EF75271-21F5-4A58-B6DA-9BE6970576BC@cs.columbia.edu> <27C1D446-6E38-4A48-8FFF-3F65EFBA104F@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: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Location hiding: Consensus? Date: Wed, 9 May 2007 21:50:05 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 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 On May 9, 2007, at 9:31 PM, Andrew Newton wrote: > > On May 9, 2007, at 11:22 AM, Henning Schulzrinne wrote: >> Are you suggesting that, from a technical standpoint, hiding >> location from the end system is a good idea? > > I think you misunderstood my point. Simply put, if you are going > through the trouble to support location hiding, you should support > it fully and not partially. Why? We're engineering for requirements, not some abstract ideal of perfection, particularly since that perfection is about as far away from where we want to be without the business issue. After all, location hiding isn't the architecture that the working group agreed upon. Thus, I think the right model is to what we need to do, but no more. > >> Unfortunately, in your model, the VSP would have no way to do any >> validation at all, since it is not operating a trusted LoST >> server, according to our 'no business relationship' requirement >> and thus can't resolve the reference. Thus, your model actually >> fails to support the validation requirements. That's certainly >> good to note. > > Hmmm... yet in your model, the PSAP is somehow known as a trusted > entity when dereferencing location. In whatever way that occurs, > which has not been explained, the VSP can also use that trust > relationship to determine if it is sending calls to a PSAP. PSAPs and ISPs are not competing with each other, ISPs (in their often dual role as VSPs) and VSPs are. Also, the number of PSAPs per ISP is very small, compared to the number of VSPs. There is no way that an ISP can know all the VSPs in the world. I don't like this trust relationship, but it's been proposed by others for other reasons (location signing), and I don't recall you objecting at that point. > > There is another issue with the validation step. Taking Brian's > now-infamous VSP in Sierra Leone, how can you be assured that the > LoST tree used by the VSP is capable of traversing to the LoST tree > used by the LIS? > For any number of reasons, we need a global LoST tree if the Sierra Leonian VSP is to work at all for roaming users, location hiding or not. We can't count on every ISP offering LoST services, for example. >> I'm using Brian's variation of my proposal. The LIS computes, >> based on its querying of LoST, a geometric shape such as a polygon >> or circle whose centroid/center lands in the right PSAP and >> includes the current location of the client, presumably somewhere >> other than in the center. >> >> The VSP does exactly the same computation, again taking the center >> of the circle to do the lookup. Thus, it performs no special >> operation and is not concerned with holes in service areas at all. > > Since the computation is the same, why not just send the point that > is the centroid? We don't want to lie by pretending that the client is somewhere where it isn't. In the centroid model, we simply artificially "fuzz" the location information. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 09 22:06:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hly3S-0008R9-Uy; Wed, 09 May 2007 22:06:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hly3R-0008Qe-Ac for ecrit@ietf.org; Wed, 09 May 2007 22:06:53 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hly3P-0005RC-Uc for ecrit@ietf.org; Wed, 09 May 2007 22:06:53 -0400 X-SEF-Processed: 5_0_0_910__2007_05_09_21_13_47 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 09 May 2007 21:13:47 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 21:06:46 -0500 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] Location hiding: Consensus? Date: Wed, 9 May 2007 21:06:44 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location hiding: Consensus? Thread-Index: AceSpZL+HMQVcuPpQGG1afMA+HlDBgAAG/ow From: "Winterbottom, James" To: "Henning Schulzrinne" , "Andrew Newton" X-OriginalArrivalTime: 10 May 2007 02:06:46.0775 (UTC) FILETIME=[DCF78070:01C792A7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 have tried really hard not to chime on this argument except to try and=0D= =0Apoint out some of the impracticalities of some aspects. But this email=0D= =0Arequires some responses.=0D=0A=0D=0AFirstly, without the business model = this is not going happen=0D=0Aalternatives will be found, and they will lik= ely be local derivatives.=0D=0ABusiness requirements are requirements none = the less and to ignore this=0D=0Afact is silly. Two major carriers on this = list have indicated that they=0D=0Awill deploy this kind of solution, we ca= n bury our heads in the sand, or=0D=0Awe can solve it. See below that I thi= nk any kind of providing partial=0D=0Alocation is a bad idea.=0D=0A=0D=0AI = don't really see ISPs necessarily competing with VSPs, they may in=0D=0Asom= e cases but they certainly don't in others. The example is exactly=0D=0Athe= Brian's Sierra Leone case, how is my home VSP in Sierra Leone=0D=0Acompeti= ng with my the ISP serving my hotel in Minneapolis=3F=0D=0A=0D=0AIf I provi= de an end-point a fuzzed location how do they know what it is=0D=0Arestrict= ed to=3F If it is good enough for a LoST server to then provide=0D=0Athem w= ith a PSAP URI, how do you ensure without a doubt that it isn't=0D=0Agood e= nough to get them to a Pizza hut=3F How do you ensure that the=0D=0Acentroi= d will get them to the right Pizza hut=3F How do you stop thw wrong=0D=0Api= zza hut from getting really annoyed because they keeping getting=0D=0Aincor= rect calls=3F The list goes on. Not to mention, that a LIS that did=0D=0An= ot previously need to know anything about service boundaries now needs=0D=0A= to compute them. Please read this as "I really really really hate any=0D=0A= solution that requires a LIS or LIS operator to do this".=20=0D=0A=0D=0AI w= ould also like to stress that I think that this is as much a GeoPriv=0D=0Ap= roblem as it is an ECRIT problem.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A>= -----Original Message-----=0D=0A> From: Henning Schulzrinne [mailto:hgs@cs= =2Ecolumbia.edu]=0D=0A> Sent: Thursday, 10 May 2007 11:50 AM=0D=0A> To: And= rew Newton=0D=0A> Cc: ECRIT=0D=0A> Subject: Re: [Ecrit] Location hiding: Co= nsensus=3F=0D=0A>=20=0D=0A>=20=0D=0A> On May 9, 2007, at 9:31 PM, Andrew Ne= wton wrote:=0D=0A>=20=0D=0A> >=0D=0A> > On May 9, 2007, at 11:22 AM, Hennin= g Schulzrinne wrote:=0D=0A> >> Are you suggesting that, from a technical st= andpoint, hiding=0D=0A> >> location from the end system is a good idea=3F=0D= =0A> >=0D=0A> > I think you misunderstood my point. Simply put, if you are= going=0D=0A> > through the trouble to support location hiding, you should = support=0D=0A> > it fully and not partially.=0D=0A>=20=0D=0A> Why=3F We're = engineering for requirements, not some abstract ideal of=0D=0A> perfection,= particularly since that perfection is about as far away=0D=0A> from where = we want to be without the business issue. After all,=0D=0A> location hiding= isn't the architecture that the working group agreed=0D=0A> upon. Thus, I = think the right model is to what we need to do, but no=0D=0A> more.=0D=0A> =0D= =0A> >=0D=0A> >> Unfortunately, in your model, the VSP would have no way to= do any=0D=0A> >> validation at all, since it is not operating a trusted Lo= ST=0D=0A> >> server, according to our 'no business relationship' requiremen= t=0D=0A> >> and thus can't resolve the reference. Thus, your model actually=0D= =0A> >> fails to support the validation requirements. That's certainly=0D=0A= > >> good to note.=0D=0A> >=0D=0A> > Hmmm... yet in your model, the PSAP is= somehow known as a trusted=0D=0A> > entity when dereferencing location. I= n whatever way that occurs,=0D=0A> > which has not been explained, the VSP = can also use that trust=0D=0A> > relationship to determine if it is sending= calls to a PSAP.=0D=0A>=20=0D=0A> PSAPs and ISPs are not competing with ea= ch other, ISPs (in their=0D=0A> often dual role as VSPs) and VSPs are. Also= , the number of PSAPs per=0D=0A> ISP is very small, compared to the number = of VSPs. There is no way=0D=0A> that an ISP can know all the VSPs in the wo= rld.=0D=0A>=20=0D=0A> I don't like this trust relationship, but it's been p= roposed by=0D=0A> others for other reasons (location signing), and I don't = recall you=0D=0A> objecting at that point.=0D=0A>=20=0D=0A>=20=0D=0A> >=0D=0A= > > There is another issue with the validation step. Taking Brian's=0D=0A>= > now-infamous VSP in Sierra Leone, how can you be assured that the=0D=0A>= > LoST tree used by the VSP is capable of traversing to the LoST tree=0D=0A= > > used by the LIS=3F=0D=0A> >=0D=0A>=20=0D=0A> For any number of reasons,= we need a global LoST tree if the Sierra=0D=0A> Leonian VSP is to work at = all for roaming users, location hiding or=0D=0A> not. We can't count on eve= ry ISP offering LoST services, for example.=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D= =0A> >> I'm using Brian's variation of my proposal. The LIS computes,=0D=0A= > >> based on its querying of LoST, a geometric shape such as a polygon=0D=0A= > >> or circle whose centroid/center lands in the right PSAP and=0D=0A> >> = includes the current location of the client, presumably somewhere=0D=0A> >>= other than in the center.=0D=0A> >>=0D=0A> >> The VSP does exactly the sam= e computation, again taking the center=0D=0A> >> of the circle to do the lo= okup. Thus, it performs no special=0D=0A> >> operation and is not concerned= with holes in service areas at all.=0D=0A> >=0D=0A> > Since the computatio= n is the same, why not just send the point that=0D=0A> > is the centroid=3F=0D= =0A>=20=0D=0A> We don't want to lie by pretending that the client is somewh= ere where=0D=0A> it isn't. In the centroid model, we simply artificially "f= uzz" the=0D=0A> location information.=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> = >=0D=0A> > -andy=0D=0A>=20=0D=0A>=20=0D=0A> _______________________________= ________________=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> htt= ps://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A----------------------= --------------------------------------------------------------------------=0D= =0AThis message is for the designated recipient only and may=0D=0Acontain p= rivileged, proprietary, or otherwise private information. =20=0D=0AIf you h= ave received it in error, please notify the sender=0D=0Aimmediately and del= ete the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 09 22:32:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlyS4-0007gq-Va; Wed, 09 May 2007 22:32:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlyS4-0007cE-6u for ecrit@ietf.org; Wed, 09 May 2007 22:32:20 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlyS3-0000Fi-VK for ecrit@ietf.org; Wed, 09 May 2007 22:32:20 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l4A2W8a0021963 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 9 May 2007 22:32:13 -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: <969E672C-2BB1-490A-BEF5-8B7F30E51BA8@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Location hiding: Consensus? Date: Wed, 9 May 2007 22:32:06 -0400 To: "Winterbottom, James" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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 On May 9, 2007, at 10:06 PM, Winterbottom, James wrote: > > Firstly, without the business model this is not going happen > alternatives will be found, and they will likely be local derivatives. > Business requirements are requirements none the less and to ignore > this > fact is silly. Two major carriers on this list have indicated that > they > will deploy this kind of solution, we can bury our heads in the > sand, or > we can solve it. See below that I think any kind of providing partial > location is a bad idea. > If you recall the earlier discussion, we had already agreed that revealing the PSAP URL effectively reveals the PSAP coverage area, since this is generally public. Thus, trying to hide anything below that level is pointless, even if you don't believe in the fact that IP address-based location is, in most cases, at least as precise. > I don't really see ISPs necessarily competing with VSPs, they may in > some cases but they certainly don't in others. The example is exactly > the Brian's Sierra Leone case, how is my home VSP in Sierra Leone > competing with my the ISP serving my hotel in Minneapolis? They may not be, but the solution has to work even if they are competing. Let's say I set up a VSP that believes that location information should be freely given to my customers. You are now prohibiting me from serving my customers if I don't sign your NDA? How would you enforce that the Sierra Leonian VSP doesn't hand out location information to their customers? Should every ISP sign an NDA with every VSP? I'm sorry, but we are not going to make progress if we re-argue the core ECRIT assumptions for each problem. The 'no business relationship' assumption has been in our requirements document from the very beginning. It might even be in the charter discussion. > > If I provide an end-point a fuzzed location how do they know what > it is > restricted to? If it is good enough for a LoST server to then provide > them with a PSAP URI, how do you ensure without a doubt that it isn't > good enough to get them to a Pizza hut? How do you ensure that the > centroid will get them to the right Pizza hut? How do you stop thw > wrong > pizza hut from getting really annoyed because they keeping getting > incorrect calls? The list goes on. Not to mention, that a LIS that > did > not previously need to know anything about service boundaries now > needs > to compute them. Please read this as "I really really really hate any > solution that requires a LIS or LIS operator to do this". ECRIT is solving the emergency calling problem. Besides, the same problem will occur with any non-precise information, whether this is cell-sector or this artificially fuzzed data. As far as I can tell, you have not been objecting to delivering cell-sector information to end users. > > I would also like to stress that I think that this is as much a > GeoPriv > problem as it is an ECRIT problem. > I'm sure that adding another working group is going to help us make progress... > Cheers > James > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 09 23:43:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlzYc-0000Bi-E0; Wed, 09 May 2007 23:43:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlzYa-0000BS-T1 for ecrit@ietf.org; Wed, 09 May 2007 23:43:08 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlzYW-0004I1-IO for ecrit@ietf.org; Wed, 09 May 2007 23:43:08 -0400 X-SEF-Processed: 5_0_0_910__2007_05_09_22_50_05 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 09 May 2007 22:50:05 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 22:43:04 -0500 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] Location hiding: Consensus? Date: Wed, 9 May 2007 22:43:01 -0500 Message-ID: In-Reply-To: <969E672C-2BB1-490A-BEF5-8B7F30E51BA8@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location hiding: Consensus? Thread-Index: AceSq28mNuoDj+h3TwOHMWO9Q70fdQAB/v6A From: "Winterbottom, James" To: "Henning Schulzrinne" X-OriginalArrivalTime: 10 May 2007 03:43:04.0091 (UTC) FILETIME=[5083F6B0:01C792B5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 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 Your responses miss the point in almost all cases.=0D=0A=0D=0AIf you want t= o use IP to location database outside of my access network=0D=0Acontrol ple= ase go ahead. I will certainly not be held accountable for=0D=0Aproviding y= ou incorrect information, so I agree there may be=0D=0Aalternatives, but th= ey are not my concern, and if you choose to use them=0D=0Aon your head be i= t.=0D=0A=0D=0AIf I give you a series of PSAP URIs and you choose to reverse= engineer=0D=0Athe service boundary, again that is your prerogative, and I = can't stop=0D=0Ayou from doing it. It doesn't however, except in some very = special=0D=0Acircumstances, tell you precisely where you are.=0D=0A=0D=0AAs= far as I can tell, LoST says currently, if you push in a location, it=0D=0A= can push out a few things, one of which is the uri of a PSAP. It doesn't=0D= =0Asay that this MUST be the end-point, if it did, then the whole=0D=0Aretr= ansmission-allowed discussion is moot. I have made no attempt to=0D=0Achang= e this premise.=0D=0A=0D=0AI simply do not understand your "business relati= onships" arguments.=0D=0AECRIT is, as far as I am concerned, directed at ro= uting emergency calls.=0D=0AIt has always explicitly stated that how an end= -point learns it location=0D=0Aor otherwise is out of scope and a geopriv p= roblem. So I put to you the=0D=0Afollowing the scenario, and perhaps you ca= n explain to me where the=0D=0A"business relationship" impact comes into pl= ay.=0D=0A=0D=0A1) I ask the LIS for a location, it gives me back a bunch of= dial=0D=0Astrings, a corresponding bunch of PSAP URIs, and a location refe= rence.=0D=0A(so far no business relationship).=0D=0A=0D=0A2) I make a call = through my VSP in Sierra Leone (UAC to VSP relationship=0D=0Abut this has a= lways been agreed to).=0D=0A=0D=0A3a) VSP routes call to PSAP (I have a mon= thly calling plan), PSAP=0D=0Aanswers call and uses reference (no business = relationship)=0D=0A=0D=0A3b) VSP wants to check the URI, it uses a yet to b= e built LoST interface=0D=0Athat does URI to service mapping, and either bi= lls me, or pushes the=0D=0Acall to the PSAP (no business relationship).=0D=0A=0D= =0AThis is all in scope for ECRIT, and seems fine to me.=0D=0A=0D=0AIf I wa= nt to use location for other services, nobody has said that the=0D=0Aaccess= network provider should not be able to charge for this. are you=0D=0Asayin= g that they should not be allowed to charge for this=3F=0D=0A=0D=0ACheers=0D= =0AJames=0D=0A=0D=0A=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: H= enning Schulzrinne [mailto:hgs@cs.columbia.edu]=0D=0A> Sent: Thursday, 10 M= ay 2007 12:32 PM=0D=0A> To: Winterbottom, James=0D=0A> Cc: ECRIT=0D=0A> Sub= ject: Re: [Ecrit] Location hiding: Consensus=3F=0D=0A>=20=0D=0A>=20=0D=0A> = On May 9, 2007, at 10:06 PM, Winterbottom, James wrote:=0D=0A>=20=0D=0A> >=0D= =0A> > Firstly, without the business model this is not going happen=0D=0A> = > alternatives will be found, and they will likely be local=0D=0Aderivative= s.=0D=0A> > Business requirements are requirements none the less and to ign= ore=0D=0A> > this=0D=0A> > fact is silly. Two major carriers on this list h= ave indicated that=0D=0A> > they=0D=0A> > will deploy this kind of solution= , we can bury our heads in the=0D=0A> > sand, or=0D=0A> > we can solve it. = See below that I think any kind of providing=0D=0Apartial=0D=0A> > location= is a bad idea.=0D=0A> >=0D=0A>=20=0D=0A> If you recall the earlier discuss= ion, we had already agreed that=0D=0A> revealing the PSAP URL effectively r= eveals the PSAP coverage area,=0D=0A> since this is generally public. Thus,= trying to hide anything below=0D=0A> that level is pointless, even if you = don't believe in the fact that=0D=0A> IP address-based location is, in most= cases, at least as precise.=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> > I don't= really see ISPs necessarily competing with VSPs, they may in=0D=0A> > some= cases but they certainly don't in others. The example is=0D=0Aexactly=0D=0A= > > the Brian's Sierra Leone case, how is my home VSP in Sierra Leone=0D=0A= > > competing with my the ISP serving my hotel in Minneapolis=3F=0D=0A>=20=0D= =0A> They may not be, but the solution has to work even if they are=0D=0A> = competing. Let's say I set up a VSP that believes that location=0D=0A> info= rmation should be freely given to my customers. You are now=0D=0A> prohibit= ing me from serving my customers if I don't sign your NDA=3F=0D=0A> How wou= ld you enforce that the Sierra Leonian VSP doesn't hand out=0D=0A> location= information to their customers=3F Should every ISP sign an NDA=0D=0A> with= every VSP=3F=0D=0A>=20=0D=0A> I'm sorry, but we are not going to make prog= ress if we re-argue the=0D=0A> core ECRIT assumptions for each problem. The= 'no business=0D=0A> relationship' assumption has been in our requirements = document from=0D=0A> the very beginning. It might even be in the charter di= scussion.=0D=0A>=20=0D=0A>=20=0D=0A> >=0D=0A> > If I provide an end-point a= fuzzed location how do they know what=0D=0A> > it is=0D=0A> > restricted t= o=3F If it is good enough for a LoST server to then=0D=0Aprovide=0D=0A> > t= hem with a PSAP URI, how do you ensure without a doubt that it=0D=0Aisn't=0D= =0A> > good enough to get them to a Pizza hut=3F How do you ensure that the=0D= =0A> > centroid will get them to the right Pizza hut=3F How do you stop thw=0D= =0A> > wrong=0D=0A> > pizza hut from getting really annoyed because they ke= eping getting=0D=0A> > incorrect calls=3F The list goes on. Not to mention= , that a LIS that=0D=0A> > did=0D=0A> > not previously need to know anythin= g about service boundaries now=0D=0A> > needs=0D=0A> > to compute them. Ple= ase read this as "I really really really hate=0D=0Aany=0D=0A> > solution th= at requires a LIS or LIS operator to do this".=0D=0A>=20=0D=0A> ECRIT is so= lving the emergency calling problem. Besides, the same=0D=0A> problem will = occur with any non-precise information, whether this is=0D=0A> cell-sector = or this artificially fuzzed data. As far as I can tell,=0D=0A> you have not= been objecting to delivering cell-sector information to=0D=0A> end users.=0D= =0A>=20=0D=0A>=20=0D=0A> >=0D=0A> > I would also like to stress that I thin= k that this is as much a=0D=0A> > GeoPriv=0D=0A> > problem as it is an ECRI= T problem.=0D=0A> >=0D=0A>=20=0D=0A> I'm sure that adding another working g= roup is going to help us make=0D=0A> progress...=0D=0A>=20=0D=0A> > Cheers=0D= =0A> > James=0D=0A> >=0D=0A>=20=0D=0A=0D=0A--------------------------------= ----------------------------------------------------------------=0D=0AThis = message is for the designated recipient only and may=0D=0Acontain privilege= d, proprietary, or otherwise private information. =20=0D=0AIf you have rece= ived it in error, please notify the sender=0D=0Aimmediately and delete the = original. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A----= ---------------------------------------------------------------------------= -----------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu May 10 10:15:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm9Q7-0007zy-R7; Thu, 10 May 2007 10:15:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm9Q6-0007zq-8r for ecrit@ietf.org; Thu, 10 May 2007 10:15:02 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm9Q4-000771-Tx for ecrit@ietf.org; Thu, 10 May 2007 10:15:02 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Hm9Q4-00024Q-3I; Thu, 10 May 2007 10:15:00 -0400 Message-ID: <464328FA.9010803@bbn.com> Date: Thu, 10 May 2007 10:15:22 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Location hiding: Consensus? References: <969E672C-2BB1-490A-BEF5-8B7F30E51BA8@cs.columbia.edu> In-Reply-To: <969E672C-2BB1-490A-BEF5-8B7F30E51BA8@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 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 Just to address the point of relevance to GEOPRIV: Proposal 1 does raise GEOPRIV concerns because it requires the LIS to give out location to unauthorized entities. Even if there's strong randomness in the LbyR, if someone does manage to guess or steal the LbyR, then the LIS MUST give that party the endpoint's rough location. Speaking with a GEOPRIV hat on, that's not OK. However, the "rough location" proposal, in the abstract, does not require this. For instance Proposal 1B (that I added to Hannes' wiki yesterday) uses the LCP for delivery of rough location to the endpoint only. --Richard Henning Schulzrinne wrote: > > On May 9, 2007, at 10:06 PM, Winterbottom, James wrote: > >> >> Firstly, without the business model this is not going happen >> alternatives will be found, and they will likely be local derivatives. >> Business requirements are requirements none the less and to ignore this >> fact is silly. Two major carriers on this list have indicated that they >> will deploy this kind of solution, we can bury our heads in the sand, or >> we can solve it. See below that I think any kind of providing partial >> location is a bad idea. >> > > If you recall the earlier discussion, we had already agreed that > revealing the PSAP URL effectively reveals the PSAP coverage area, since > this is generally public. Thus, trying to hide anything below that level > is pointless, even if you don't believe in the fact that IP > address-based location is, in most cases, at least as precise. > > > >> I don't really see ISPs necessarily competing with VSPs, they may in >> some cases but they certainly don't in others. The example is exactly >> the Brian's Sierra Leone case, how is my home VSP in Sierra Leone >> competing with my the ISP serving my hotel in Minneapolis? > > They may not be, but the solution has to work even if they are > competing. Let's say I set up a VSP that believes that location > information should be freely given to my customers. You are now > prohibiting me from serving my customers if I don't sign your NDA? How > would you enforce that the Sierra Leonian VSP doesn't hand out location > information to their customers? Should every ISP sign an NDA with every > VSP? > > I'm sorry, but we are not going to make progress if we re-argue the core > ECRIT assumptions for each problem. The 'no business relationship' > assumption has been in our requirements document from the very > beginning. It might even be in the charter discussion. > > >> >> If I provide an end-point a fuzzed location how do they know what it is >> restricted to? If it is good enough for a LoST server to then provide >> them with a PSAP URI, how do you ensure without a doubt that it isn't >> good enough to get them to a Pizza hut? How do you ensure that the >> centroid will get them to the right Pizza hut? How do you stop thw wrong >> pizza hut from getting really annoyed because they keeping getting >> incorrect calls? The list goes on. Not to mention, that a LIS that did >> not previously need to know anything about service boundaries now needs >> to compute them. Please read this as "I really really really hate any >> solution that requires a LIS or LIS operator to do this". > > ECRIT is solving the emergency calling problem. Besides, the same > problem will occur with any non-precise information, whether this is > cell-sector or this artificially fuzzed data. As far as I can tell, you > have not been objecting to delivering cell-sector information to end users. > > >> >> I would also like to stress that I think that this is as much a GeoPriv >> problem as it is an ECRIT problem. >> > > I'm sure that adding another working group is going to help us make > progress... > >> Cheers >> James >> > > > _______________________________________________ > 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 May 10 10:24:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm9Z7-0006xQ-4D; Thu, 10 May 2007 10:24:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm9Z5-0006xF-TO for ecrit@ietf.org; Thu, 10 May 2007 10:24:19 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hm9Z3-0003gg-ID for ecrit@ietf.org; Thu, 10 May 2007 10:24:19 -0400 Received: from [160.39.254.11] (dyn-160-39-254-11.dyn.columbia.edu [160.39.254.11]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l4AEO0BA029824 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 10 May 2007 10:24:05 -0400 (EDT) In-Reply-To: <464328FA.9010803@bbn.com> References: <969E672C-2BB1-490A-BEF5-8B7F30E51BA8@cs.columbia.edu> <464328FA.9010803@bbn.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Location hiding: Consensus? Date: Thu, 10 May 2007 10:24:00 -0400 To: Richard Barnes X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 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 The reference is carried in exactly the same protocols as a value would be, so the exposure to third parties is exactly the same. We have assumed all along that the URL is not guessable. On May 10, 2007, at 10:15 AM, Richard Barnes wrote: > Just to address the point of relevance to GEOPRIV: > > Proposal 1 does raise GEOPRIV concerns because it requires the LIS > to give out location to unauthorized entities. Even if there's > strong randomness in the LbyR, if someone does manage to guess or > steal the LbyR, then the LIS MUST give that party the endpoint's > rough location. Speaking with a GEOPRIV hat on, that's not OK. > > However, the "rough location" proposal, in the abstract, does not > require this. For instance Proposal 1B (that I added to Hannes' > wiki yesterday) uses the LCP for delivery of rough location to the > endpoint only. > LocationHiding> > > --Richard > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu May 10 10:32:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm9go-00049L-3R; Thu, 10 May 2007 10:32:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm9gm-00049F-Uj for ecrit@ietf.org; Thu, 10 May 2007 10:32:16 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm9gl-0001zq-Nf for ecrit@ietf.org; Thu, 10 May 2007 10:32:16 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Hm9gl-0002JY-4M; Thu, 10 May 2007 10:32:15 -0400 Message-ID: <46432D05.7040102@bbn.com> Date: Thu, 10 May 2007 10:32:37 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Location hiding: Consensus? References: <969E672C-2BB1-490A-BEF5-8B7F30E51BA8@cs.columbia.edu> <464328FA.9010803@bbn.com> 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: e1e48a527f609d1be2bc8d8a70eb76cb 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 It should be noted, however, that it will be necessary to standardize that assumption, including a definition of "not guessable" and likely some documentation of how to make such URLs. Why not just avoid this pothole and use the LCP instead of the dereference protocol? Architecturally, they're playing the same role (delivering rough location to the endpoint), but using the LCP doesn't have these privacy concerns. --Richard Henning Schulzrinne wrote: > The reference is carried in exactly the same protocols as a value would > be, so the exposure to third parties is exactly the same. We have > assumed all along that the URL is not guessable. > > On May 10, 2007, at 10:15 AM, Richard Barnes wrote: > >> Just to address the point of relevance to GEOPRIV: >> >> Proposal 1 does raise GEOPRIV concerns because it requires the LIS to >> give out location to unauthorized entities. Even if there's strong >> randomness in the LbyR, if someone does manage to guess or steal the >> LbyR, then the LIS MUST give that party the endpoint's rough location. >> Speaking with a GEOPRIV hat on, that's not OK. >> >> However, the "rough location" proposal, in the abstract, does not >> require this. For instance Proposal 1B (that I added to Hannes' wiki >> yesterday) uses the LCP for delivery of rough location to the endpoint >> only. >> >> >> >> --Richard >> > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu May 10 10:39:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm9o2-0005tf-Oe; Thu, 10 May 2007 10:39:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm9o1-0005tR-Hi for ecrit@ietf.org; Thu, 10 May 2007 10:39:45 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm9o0-0003O9-BF for ecrit@ietf.org; Thu, 10 May 2007 10:39:45 -0400 Received: from [160.39.254.11] (dyn-160-39-254-11.dyn.columbia.edu [160.39.254.11]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l4AEdRw1006347 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 10 May 2007 10:39:32 -0400 (EDT) In-Reply-To: <46432D05.7040102@bbn.com> References: <969E672C-2BB1-490A-BEF5-8B7F30E51BA8@cs.columbia.edu> <464328FA.9010803@bbn.com> <46432D05.7040102@bbn.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Location hiding: Consensus? Date: Thu, 10 May 2007 10:39:27 -0400 To: Richard Barnes X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 There is already an RFC describing how to build cryptographically random numbers, which can be easily cited. On May 10, 2007, at 10:32 AM, Richard Barnes wrote: > It should be noted, however, that it will be necessary to > standardize that assumption, including a definition of "not > guessable" and likely some documentation of how to make such URLs. > > Why not just avoid this pothole and use the LCP instead of the > dereference protocol? Architecturally, they're playing the same > role (delivering rough location to the endpoint), but using the LCP > doesn't have these privacy concerns. > > --Richard > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu May 10 10:43:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm9rT-00016z-4c; Thu, 10 May 2007 10:43:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm9rR-00014A-3u for ecrit@ietf.org; Thu, 10 May 2007 10:43:17 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm9rP-00046y-Fo for ecrit@ietf.org; Thu, 10 May 2007 10:43:17 -0400 Received: from mail2.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id l4AEg0IA007843; Thu, 10 May 2007 16:42:00 +0200 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id l4AEg0ZT010535; Thu, 10 May 2007 16:42:00 +0200 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 16:42:00 +0200 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: AW: [Ecrit] Location hiding: Consensus? Date: Thu, 10 May 2007 16:41:54 +0200 Message-ID: <8F6CBC7005099442AECDB784C9E9D7E701AFF133@MCHP7R6A.ww002.siemens.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location hiding: Consensus? Thread-Index: AceTERTFZldfmrtjQVKK5TliPamksQAAA3Ew From: "Tschofenig, Hannes" To: "ext Henning Schulzrinne" , "Richard Barnes" X-OriginalArrivalTime: 10 May 2007 14:42:00.0626 (UTC) FILETIME=[5E207120:01C79311] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 Richard,=20 I don't see the challenges you describe. Just reference RFC 4086 and you are fine.=20 Ciao Hannes > -----Urspr=FCngliche Nachricht----- > Von: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 > Gesendet: Donnerstag, 10. Mai 2007 15:39 > An: Richard Barnes > Cc: ECRIT > Betreff: Re: [Ecrit] Location hiding: Consensus? >=20 > There is already an RFC describing how to build cryptographically =20 > random numbers, which can be easily cited. >=20 > On May 10, 2007, at 10:32 AM, Richard Barnes wrote: >=20 > > It should be noted, however, that it will be necessary to =20 > > standardize that assumption, including a definition of "not =20 > > guessable" and likely some documentation of how to make such URLs. > > > > Why not just avoid this pothole and use the LCP instead of the =20 > > dereference protocol? Architecturally, they're playing the same =20 > > role (delivering rough location to the endpoint), but using=20 > the LCP =20 > > doesn't have these privacy concerns. > > > > --Richard > > >=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 Thu May 10 13:21:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmCKx-0004YU-Vp; Thu, 10 May 2007 13:21:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmCKx-0004YP-3r for ecrit@ietf.org; Thu, 10 May 2007 13:21:55 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmCKw-0004LZ-S0 for ecrit@ietf.org; Thu, 10 May 2007 13:21:55 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1HmCKv-0001hu-4v; Thu, 10 May 2007 13:21:53 -0400 Message-ID: <464354C7.3080207@bbn.com> Date: Thu, 10 May 2007 13:22:15 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Tschofenig, Hannes" Subject: Re: AW: [Ecrit] Location hiding: Consensus? References: <8F6CBC7005099442AECDB784C9E9D7E701AFF133@MCHP7R6A.ww002.siemens.net> In-Reply-To: <8F6CBC7005099442AECDB784C9E9D7E701AFF133@MCHP7R6A.ww002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 There are certainly plenty of documented ways to go about this, but Proposal 1 would require normative language to enforce it. And, while the requirement seems clear (1. provide unauthorized access to rough location, and 2. add cryptographic randomness per RFC 4086), it's not clear which reference systems the requirement is levied on. Does this apply to all presence services that include location information useful to emergency services? Does it just apply to a LIS (and for what definition of LIS)? What if a single box is a presence server and a LIS? Why are you guys attached to using the dereference protocol to deliver rough location? What's wrong with just using the LCP? This seems like a much cleaner design. --Richard Tschofenig, Hannes wrote: > Hi Richard, > > I don't see the challenges you describe. > Just reference RFC 4086 and you are fine. > > Ciao > Hannes > >> -----Ursprüngliche Nachricht----- >> Von: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> Gesendet: Donnerstag, 10. Mai 2007 15:39 >> An: Richard Barnes >> Cc: ECRIT >> Betreff: Re: [Ecrit] Location hiding: Consensus? >> >> There is already an RFC describing how to build cryptographically >> random numbers, which can be easily cited. >> >> On May 10, 2007, at 10:32 AM, Richard Barnes wrote: >> >>> It should be noted, however, that it will be necessary to >>> standardize that assumption, including a definition of "not >>> guessable" and likely some documentation of how to make such URLs. >>> >>> Why not just avoid this pothole and use the LCP instead of the >>> dereference protocol? Architecturally, they're playing the same >>> role (delivering rough location to the endpoint), but using >> the LCP >>> doesn't have these privacy concerns. >>> >>> --Richard >>> >> >> _______________________________________________ >> 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 May 10 16:23:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmFAC-0007r6-U9; Thu, 10 May 2007 16:23:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmFAB-0007r1-O8 for ecrit@ietf.org; Thu, 10 May 2007 16:22:59 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmFAA-0003cC-A3 for ecrit@ietf.org; Thu, 10 May 2007 16:22:59 -0400 Received: from dhcp89-089-076.bbn.com ([128.89.89.76] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1HmFA9-0007Kx-61; Thu, 10 May 2007 16:22:57 -0400 Message-ID: <46437EFD.7090201@bbn.com> Date: Thu, 10 May 2007 16:22:21 -0400 From: Matt Lepinski Organization: BBN User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Winterbottom, James" Subject: Re: [Ecrit] Location hiding: Consensus? 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: 17bdfcaea25d1444baef0e24abc38874 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'm really trying to understand the fundamental disagreement between James and Henning and I'm failing completely. Any clarification of the following points would be greatly appreciated. 1) I believe James began by stating that there are business requirements for location hiding, and that these are real requirements. I believe everyone participating in this thread agrees on that point. (Ignoring any value judgement about whether these requirements are good or evil) 2) James seems to believe that providing "fuzzed" location to the end-point is a bad idea. This would seem to be a fundamental source of disagreement with Henning who has supported sending "fuzzed" location to the end-point. Henning's argument seems to be that PSAP URI is already a form of "fuzzed" location that we're already providing, and James seems to be concerned with the access network provider being held accountable for providing "low quality" location. Is this understanding correct? 3)The whole business relationships argument is especially confusing to me since it seems that both Henning and James agree that ISPs should not be required to have business relationships with VSPs. (I don't think I've heard anyone in this thread argue against that basic point). It is reasonable to say that a particular proposal is bad because it would require contractual relationships between ISPs and VSPs, but so far I don't think I've heard James argue in support of any particular proposal. Thanks for the clarification, sorry if I'm just being dense, - Matt Lepinski :-> Winterbottom, James wrote: >Your responses miss the point in almost all cases. > >If you want to use IP to location database outside of my access network >control please go ahead. I will certainly not be held accountable for >providing you incorrect information, so I agree there may be >alternatives, but they are not my concern, and if you choose to use them >on your head be it. > >If I give you a series of PSAP URIs and you choose to reverse engineer >the service boundary, again that is your prerogative, and I can't stop >you from doing it. It doesn't however, except in some very special >circumstances, tell you precisely where you are. > >As far as I can tell, LoST says currently, if you push in a location, it >can push out a few things, one of which is the uri of a PSAP. It doesn't >say that this MUST be the end-point, if it did, then the whole >retransmission-allowed discussion is moot. I have made no attempt to >change this premise. > >I simply do not understand your "business relationships" arguments. >ECRIT is, as far as I am concerned, directed at routing emergency calls. >It has always explicitly stated that how an end-point learns it location >or otherwise is out of scope and a geopriv problem. So I put to you the >following the scenario, and perhaps you can explain to me where the >"business relationship" impact comes into play. > >1) I ask the LIS for a location, it gives me back a bunch of dial >strings, a corresponding bunch of PSAP URIs, and a location reference. >(so far no business relationship). > >2) I make a call through my VSP in Sierra Leone (UAC to VSP relationship >but this has always been agreed to). > >3a) VSP routes call to PSAP (I have a monthly calling plan), PSAP >answers call and uses reference (no business relationship) > >3b) VSP wants to check the URI, it uses a yet to be built LoST interface >that does URI to service mapping, and either bills me, or pushes the >call to the PSAP (no business relationship). > >This is all in scope for ECRIT, and seems fine to me. > >If I want to use location for other servic > network provider should not be able to charge for this. are you >saying that they should not be allowed to charge for this? > >Cheers >James > > > > > >>-----Original Message----- >>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>Sent: Thursday, 10 May 2007 12:32 PM >>To: Winterbottom, James >>Cc: ECRIT >>Subject: Re: [Ecrit] Location hiding: Consensus? >> >> >>On May 9, 2007, at 10:06 PM, Winterbottom, James wrote: >> >> >> >>>Firstly, without the business model this is not going happen >>>alternatives will be found, and they will likely be local >>> >>> >derivatives. > > >>>Business requirements are requirements none the less and to ignore >>>this >>>fact is silly. Two major carriers on this list have indicated that >>>they >>>will deploy this kind of solution, we can bury our heads in the >>>sand, or >>>we can solve it. See below that I think any kind of providing >>> >>> >partial > > >>>location is a bad idea. >>> >>> >>> >>If you recall the earlier discussion, we had already agreed that >>revealing the PSAP URL effectively reveals the PSAP coverage area, >>since this is generally public. Thus, trying to hide anything below >>that level is pointless, even if you don't believe in the fact that >>IP address-based location is, in most cases, at least as precise. >> >> >> >> >> >>>I don't really see ISPs necessarily competing with VSPs, they may in >>>some cases but they certainly don't in others. The example is >>> >>> >exactly > > >>>the Brian's Sierra Leone case, how is my home VSP in Sierra Leone >>>competing with my the ISP serving my hotel in Minneapolis? >>> >>> >>They may not be, but the solution has to work even if they are >>competing. Let's say I set up a VSP that believes that location >>information should be freely given to my customers. You are now >>prohibiting me from serving my customers if I don't sign your NDA? >>How would you enforce that the Sierra Leonian VSP doesn't hand out >>location information to their customers? Should every ISP sign an NDA >>with every VSP? >> >>I'm sorry, >> >> >ress if we re-argue the > > >>core ECRIT assumptions for each problem. The 'no business >>relationship' assumption has been in our requirements document from >>the very beginning. It might even be in the charter discussion. >> >> >> >> >>>If I provide an end-point a fuzzed location how do they know what >>>it is >>>restricted to? If it is good enough for a LoST server to then >>> >>> >provide > > >>>them with a PSAP URI, how do you ensure without a doubt that it >>> >>> >isn't > > >>>good enough to get them to a Pizza hut? How do you ensure that the >>>centroid will get them to the right Pizza hut? How do you stop thw >>>wrong >>>pizza hut from getting really annoyed because they keeping getting >>>incorrect calls? The list goes on. Not to mention, that a LIS that >>>did >>>not previously need to know anything about service boundaries now >>>needs >>>to compute them. Please read this as "I really really really hate >>> >>> >any > > >>>solution that requires a LIS or LIS operator to do this". >>> >>> >>ECRIT is solving the emergency calling problem. Besides, the same >>problem will occur with any non-precise information, whether this is >>cell-sector or this artificially fuzzed data. As far as I can tell, >>you have not been objecting to delivering cell-sector information to >>end users. >> >> >> >> >>>I would also like to stress that I think that this is as much a >>>GeoPriv >>>problem as it is an ECRIT problem. >>> >>> >>> >>I'm sure that adding another working group is going to help us make >>progress... >> >> >> >>>Cheers >>>James >>> >>> >>> > >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[m > >_______________________________________________ >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 May 10 16:44:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmFUy-0005HJ-Ke; Thu, 10 May 2007 16:44:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmFUx-0005HB-Ix for ecrit@ietf.org; Thu, 10 May 2007 16:44:27 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HmFUw-0006Jn-6o for ecrit@ietf.org; Thu, 10 May 2007 16:44:27 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 10 May 2007 16:44:25 -0400 id 0158837A.46438429.00006612 In-Reply-To: <46437EFD.7090201@bbn.com> References: <46437EFD.7090201@bbn.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Location hiding: Consensus? Date: Thu, 10 May 2007 16:44:23 -0400 To: Matt Lepinski X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 On May 10, 2007, at 4:22 PM, Matt Lepinski wrote: > 1) I believe James began by stating that there are business > requirements for location hiding, and that these are real > requirements. I believe everyone participating in this thread > agrees on that point. (Ignoring any value judgement about whether > these requirements are good or evil) Well, I thought Henning disagreed with there being real business requirements. > 2) James seems to believe that providing "fuzzed" location to the > end-point is a bad idea. This would seem to be a fundamental source > of disagreement with Henning who has supported sending "fuzzed" > location to the end-point. > > Henning's argument seems to be that PSAP URI is already a form of > "fuzzed" location that we're already providing, and James seems to > be concerned with the access network provider being held > accountable for providing "low quality" location. I am not a particular fan of fuzzing either. We've got little deployment experience with this architecture and who knows what trouble this will invite. And fuzzing adds fuel to the fire for those that say VoIP 9-1-1 doesn't work or is not reliable. > Is this understanding correct? > > 3)The whole business relationships argument is especially confusing > to me since it seems that both Henning and James agree that ISPs > should not be required to have business relationships with VSPs. (I > don't think I've heard anyone in this thread argue against that > basic point). > > It is reasonable to say that a particular proposal is bad because > it would require contractual relationships between ISPs and VSPs, > but so far I don't think I've heard James argue in support of any > particular proposal. I thought James was an advocate of #3. What we seem to have an issue with is the agreement on the requirements, and this is causing people not to agree on a solution. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu May 10 17:28:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmGBU-0001IP-JN; Thu, 10 May 2007 17:28:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmGBT-0001IK-UV for ecrit@ietf.org; Thu, 10 May 2007 17:28:23 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmGBT-0002wo-Dr for ecrit@ietf.org; Thu, 10 May 2007 17:28:23 -0400 X-SEF-Processed: 5_0_0_910__2007_05_10_16_35_24 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 10 May 2007 16:35:24 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 16:28:22 -0500 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] Location hiding: Consensus? Date: Thu, 10 May 2007 16:28:21 -0500 Message-ID: In-Reply-To: <46437EFD.7090201@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location hiding: Consensus? Thread-Index: AceTQQC0vMSE6CtgQESZRJ2g2bo5zQACAQhQ From: "Winterbottom, James" To: "Matt Lepinski" X-OriginalArrivalTime: 10 May 2007 21:28:22.0975 (UTC) FILETIME=[2323A4F0:01C7934A] X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 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 Matt,=0D=0A=0D=0AMy real concern is that there is a huge difference for an = access network=0D=0Aprovider between:=0D=0A=0D=0A1) Getting a LoST server t= o return a bunch of URIs and corresponding=0D=0Aservice URNs for which it i= s designed to do based on location=0D=0Ainformation provided.=0D=0A=0D=0AAn= d=0D=0A=0D=0A2) The access network asking the LoST server for the service b= oundaries=0D=0Aof each emergency URN it knows about, performs intersection = on these,=0D=0Aand the providing the intersecting service boundary back to = the=0D=0Aend-point. Oh, and making sure that this location doesn't have mor= e than=0D=0A16 vertices and that it addresses any holes.=0D=0A=0D=0AOption = is a practical solution to a real problem, 2 is quite frankly=0D=0Aridiculo= us.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A> -----Original Message--= ---=0D=0A> From: Matt Lepinski [mailto:mlepinski@bbn.com]=0D=0A> Sent: Frid= ay, 11 May 2007 6:22 AM=0D=0A> To: Winterbottom, James=0D=0A> Cc: Henning S= chulzrinne; ECRIT=0D=0A> Subject: Re: [Ecrit] Location hiding: Consensus=3F=0D= =0A>=20=0D=0A> I'm really trying to understand the fundamental disagreement= between=0D=0A> James and Henning and I'm failing completely.=0D=0A> Any cl= arification of the following points would be greatly=0D=0Aappreciated.=0D=0A= >=20=0D=0A> 1) I believe James began by stating that there are business=0D=0A= requirements=0D=0A> for location hiding, and that these are real requiremen= ts. I believe=0D=0A> everyone participating in this thread agrees on that p= oint. (Ignoring=0D=0A> any value judgement about whether these requirements= are good or evil)=0D=0A>=20=0D=0A> 2) James seems to believe that providin= g "fuzzed" location to the=0D=0A> end-point is a bad idea. This would seem = to be a fundamental source of=0D=0A> disagreement with Henning who has supp= orted sending "fuzzed" location=0D=0Ato=0D=0A> the end-point.=0D=0A>=20=0D=0A= > Henning's argument seems to be that PSAP URI is already a form of=0D=0A> = "fuzzed" location that we're already providing, and James seems to be=0D=0A= > concerned with the access network provider being held accountable for=0D=0A= > providing "low quality" location.=0D=0A>=20=0D=0A> Is this understanding = correct=3F=0D=0A>=20=0D=0A> 3)The whole business relationships argument is = especially confusing to=0D=0A> me since it seems that both Henning and Jame= s agree that ISPs should=0D=0Anot=0D=0A> be required to have business relat= ionships with VSPs. (I don't think=0D=0A> I've heard anyone in this thread = argue against that basic point).=0D=0A>=20=0D=0A> It is reasonable to say t= hat a particular proposal is bad because it=0D=0A> would require contractua= l relationships between ISPs and VSPs, but so=0D=0A> far I don't think I've= heard James argue in support of any particular=0D=0A> proposal.=0D=0A>=20=0D= =0A> Thanks for the clarification, sorry if I'm just being dense,=0D=0A> - = Matt Lepinski :->=0D=0A>=20=0D=0A> Winterbottom, James wrote:=0D=0A>=20=0D=0A= > >Your responses miss the point in almost all cases.=0D=0A> >=0D=0A> >If y= ou want to use IP to location database outside of my access=0D=0Anetwork=0D= =0A> >control please go ahead. I will certainly not be held accountable for=0D= =0A> >providing you incorrect information, so I agree there may be=0D=0A> >= alternatives, but they are not my concern, and if you choose to use=0D=0Ath= em=0D=0A> >on your head be it.=0D=0A> >=0D=0A> >If I give you a series of P= SAP URIs and you choose to reverse=0D=0Aengineer=0D=0A> >the service bounda= ry, again that is your prerogative, and I can't=0D=0Astop=0D=0A> >you from = doing it. It doesn't however, except in some very special=0D=0A> >circumsta= nces, tell you precisely where you are.=0D=0A> >=0D=0A> >As far as I can te= ll, LoST says currently, if you push in a location,=0D=0Ait=0D=0A> >can pus= h out a few things, one of which is the uri of a PSAP. It=0D=0Adoesn't=0D=0A= > >say that this MUST be the end-point, if it did, then the whole=0D=0A> >r= etransmission-allowed discussion is moot. I have made no attempt to=0D=0A> = >change this premise.=0D=0A> >=0D=0A> >I simply do not understand your "bus= iness relationships" arguments.=0D=0A> >ECRIT is, as far as I am concerned,= directed at routing emergency=0D=0Acalls.=0D=0A> >It has always explicitly= stated that how an end-point learns it=0D=0Alocation=0D=0A> >or otherwise = is out of scope and a geopriv problem. So I put to you=0D=0Athe=0D=0A> >fol= lowing the scenario, and perhaps you can explain to me where the=0D=0A> >"b= usiness relationship" impact comes into play.=0D=0A> >=0D=0A> >1) I ask the= LIS for a location, it gives me back a bunch of dial=0D=0A> >strings, a co= rresponding bunch of PSAP URIs, and a location=0D=0Areference.=0D=0A> >(so = far no business relationship).=0D=0A> >=0D=0A> >2) I make a call through my= VSP in Sierra Leone (UAC to VSP=0D=0Arelationship=0D=0A> >but this has alw= ays been agreed to).=0D=0A> >=0D=0A> >3a) VSP routes call to PSAP (I have a= monthly calling plan), PSAP=0D=0A> >answers call and uses reference (no bu= siness relationship)=0D=0A> >=0D=0A> >3b) VSP wants to check the URI, it us= es a yet to be built LoST=0D=0Ainterface=0D=0A> >that does URI to service m= apping, and either bills me, or pushes the=0D=0A> >call to the PSAP (no bus= iness relationship).=0D=0A> >=0D=0A> >This is all in scope for ECRIT, and s= eems fine to me.=0D=0A> >=0D=0A> >If I want to use location for other servi= c=0D=0A> > network provider should not be able to charge for this. are you=0D= =0A> >saying that they should not be allowed to charge for this=3F=0D=0A> >=0D= =0A> >Cheers=0D=0A> >James=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A= > >>-----Original Message-----=0D=0A> >>From: Henning Schulzrinne [mailto:h= gs@cs.columbia.edu]=0D=0A> >>Sent: Thursday, 10 May 2007 12:32 PM=0D=0A> >>= To: Winterbottom, James=0D=0A> >>Cc: ECRIT=0D=0A> >>Subject: Re: [Ecrit] Lo= cation hiding: Consensus=3F=0D=0A> >>=0D=0A> >>=0D=0A> >>On May 9, 2007, at= 10:06 PM, Winterbottom, James wrote:=0D=0A> >>=0D=0A> >>=0D=0A> >>=0D=0A> = >>>Firstly, without the business model this is not going happen=0D=0A> >>>a= lternatives will be found, and they will likely be local=0D=0A> >>>=0D=0A> = >>>=0D=0A> >derivatives.=0D=0A> >=0D=0A> >=0D=0A> >>>Business requirements = are requirements none the less and to ignore=0D=0A> >>>this=0D=0A> >>>fact = is silly. Two major carriers on this list have indicated that=0D=0A> >>>the= y=0D=0A> >>>will deploy this kind of solution, we can bury our heads in the=0D= =0A> >>>sand, or=0D=0A> >>>we can solve it. See below that I think any kind= of providing=0D=0A> >>>=0D=0A> >>>=0D=0A> >partial=0D=0A> >=0D=0A> >=0D=0A= > >>>location is a bad idea.=0D=0A> >>>=0D=0A> >>>=0D=0A> >>>=0D=0A> >>If y= ou recall the earlier discussion, we had already agreed that=0D=0A> >>revea= ling the PSAP URL effectively reveals the PSAP coverage area,=0D=0A> >>sinc= e this is generally public. Thus, trying to hide anything below=0D=0A> >>th= at level is pointless, even if you don't believe in the fact that=0D=0A> >>= IP address-based location is, in most cases, at least as precise.=0D=0A> >>=0D= =0A> >>=0D=0A> >>=0D=0A> >>=0D=0A> >>=0D=0A> >>>I don't really see ISPs nec= essarily competing with VSPs, they may=0D=0Ain=0D=0A> >>>some cases but the= y certainly don't in others. The example is=0D=0A> >>>=0D=0A> >>>=0D=0A> >e= xactly=0D=0A> >=0D=0A> >=0D=0A> >>>the Brian's Sierra Leone case, how is my= home VSP in Sierra Leone=0D=0A> >>>competing with my the ISP serving my ho= tel in Minneapolis=3F=0D=0A> >>>=0D=0A> >>>=0D=0A> >>They may not be, but t= he solution has to work even if they are=0D=0A> >>competing. Let's say I se= t up a VSP that believes that location=0D=0A> >>information should be freel= y given to my customers. You are now=0D=0A> >>prohibiting me from serving m= y customers if I don't sign your NDA=3F=0D=0A> >>How would you enforce that= the Sierra Leonian VSP doesn't hand out=0D=0A> >>location information to t= heir customers=3F Should every ISP sign an=0D=0ANDA=0D=0A> >>with every VSP= =3F=0D=0A> >>=0D=0A> >>I'm sorry,=0D=0A> >>=0D=0A> >>=0D=0A> >ress if we re= -argue the=0D=0A> >=0D=0A> >=0D=0A> >>core ECRIT assumptions for each probl= em. The 'no business=0D=0A> >>relationship' assumption has been in our requ= irements document from=0D=0A> >>the very beginning. It might even be in the= charter discussion.=0D=0A> >>=0D=0A> >>=0D=0A> >>=0D=0A> >>=0D=0A> >>>If I= provide an end-point a fuzzed location how do they know what=0D=0A> >>>it = is=0D=0A> >>>restricted to=3F If it is good enough for a LoST server to the= n=0D=0A> >>>=0D=0A> >>>=0D=0A> >provide=0D=0A> >=0D=0A> >=0D=0A> >>>them wi= th a PSAP URI, how do you ensure without a doubt that it=0D=0A> >>>=0D=0A> = >>>=0D=0A> >isn't=0D=0A> >=0D=0A> >=0D=0A> >>>good enough to get them to a = Pizza hut=3F How do you ensure that the=0D=0A> >>>centroid will get them to= the right Pizza hut=3F How do you stop thw=0D=0A> >>>wrong=0D=0A> >>>pizza= hut from getting really annoyed because they keeping getting=0D=0A> >>>inc= orrect calls=3F The list goes on. Not to mention, that a LIS that=0D=0A> >= >>did=0D=0A> >>>not previously need to know anything about service boundari= es now=0D=0A> >>>needs=0D=0A> >>>to compute them. Please read this as "I re= ally really really hate=0D=0A> >>>=0D=0A> >>>=0D=0A> >any=0D=0A> >=0D=0A> >=0D= =0A> >>>solution that requires a LIS or LIS operator to do this".=0D=0A> >>= >=0D=0A> >>>=0D=0A> >>ECRIT is solving the emergency calling problem. Besid= es, the same=0D=0A> >>problem will occur with any non-precise information, = whether this is=0D=0A> >>cell-sector or this artificially fuzzed data. As f= ar as I can tell,=0D=0A> >>you have not been objecting to delivering cell-s= ector information to=0D=0A> >>end users.=0D=0A> >>=0D=0A> >>=0D=0A> >>=0D=0A= > >>=0D=0A> >>>I would also like to stress that I think that this is as muc= h a=0D=0A> >>>GeoPriv=0D=0A> >>>problem as it is an ECRIT problem.=0D=0A> >= >>=0D=0A> >>>=0D=0A> >>>=0D=0A> >>I'm sure that adding another working grou= p is going to help us make=0D=0A> >>progress...=0D=0A> >>=0D=0A> >>=0D=0A> = >>=0D=0A> >>>Cheers=0D=0A> >>>James=0D=0A> >>>=0D=0A> >>>=0D=0A> >>>=0D=0A>= >=0D=0A>=0D=0A>-----------------------------------------------------------= ------------=0D=0A--=0D=0A> -----------------------=0D=0A> >This message is= for the designated recipient only and may=0D=0A> >contain privileged, prop= rietary, or otherwise private information.=0D=0A> >If you have received it = in error, please notify the sender=0D=0A> >immediately and delete the origi= nal. Any unauthorized use of=0D=0A> >this email is prohibited.=0D=0A>=0D=0A= >-----------------------------------------------------------------------=0D= =0A--=0D=0A> -----------------------=0D=0A> >[m=0D=0A> >=0D=0A> >__________= _____________________________________=0D=0A> >Ecrit mailing list=0D=0A> >Ec= rit@ietf.org=0D=0A> >https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> >=0D= =0A> >=0D=0A> >=0D=0A>=20=0D=0A>=20=0D=0A=0D=0A----------------------------= --------------------------------------------------------------------=0D=0AT= his message is for the designated recipient only and may=0D=0Acontain privi= leged, proprietary, or otherwise private information. =20=0D=0AIf you have = received it in error, please notify the sender=0D=0Aimmediately and delete = the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A= ---------------------------------------------------------------------------= ---------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu May 10 17:28:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmGBy-0001lW-UV; Thu, 10 May 2007 17:28:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmGBx-0001hN-8l for ecrit@ietf.org; Thu, 10 May 2007 17:28:53 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmGBw-000344-TC for ecrit@ietf.org; Thu, 10 May 2007 17:28:53 -0400 X-SEF-Processed: 5_0_0_910__2007_05_10_16_35_54 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 10 May 2007 16:35:54 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 16:28:52 -0500 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] Location hiding: Consensus? Date: Thu, 10 May 2007 16:28:51 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location hiding: Consensus? Thread-Index: AceTRAEeYqFzbyu1R22V0mf79JAwYAABi3gQ From: "Winterbottom, James" To: "Andrew Newton" , "Matt Lepinski" X-OriginalArrivalTime: 10 May 2007 21:28:52.0616 (UTC) FILETIME=[34CE8080:01C7934A] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 am an advocate of solution 3=0D=0A=0D=0A=0D=0A> -----Original Message----= -=0D=0A> From: Andrew Newton [mailto:andy@hxr.us]=0D=0A> Sent: Friday, 11 M= ay 2007 6:44 AM=0D=0A> To: Matt Lepinski=0D=0A> Cc: Winterbottom, James; EC= RIT=0D=0A> Subject: Re: [Ecrit] Location hiding: Consensus=3F=0D=0A>=20=0D=0A= >=20=0D=0A> On May 10, 2007, at 4:22 PM, Matt Lepinski wrote:=0D=0A> > 1) I= believe James began by stating that there are business=0D=0A> > requiremen= ts for location hiding, and that these are real=0D=0A> > requirements. I be= lieve everyone participating in this thread=0D=0A> > agrees on that point. = (Ignoring any value judgement about whether=0D=0A> > these requirements are= good or evil)=0D=0A>=20=0D=0A> Well, I thought Henning disagreed with ther= e being real business=0D=0A> requirements.=0D=0A>=20=0D=0A> > 2) James seem= s to believe that providing "fuzzed" location to the=0D=0A> > end-point is = a bad idea. This would seem to be a fundamental source=0D=0A> > of disagree= ment with Henning who has supported sending "fuzzed"=0D=0A> > location to t= he end-point.=0D=0A> >=0D=0A> > Henning's argument seems to be that PSAP UR= I is already a form of=0D=0A> > "fuzzed" location that we're already provid= ing, and James seems to=0D=0A> > be concerned with the access network provi= der being held=0D=0A> > accountable for providing "low quality" location.=0D= =0A>=20=0D=0A> I am not a particular fan of fuzzing either. We've got litt= le=0D=0A> deployment experience with this architecture and who knows what=0D= =0A> trouble this will invite.=0D=0A>=20=0D=0A> And fuzzing adds fuel to th= e fire for those that say VoIP 9-1-1=0D=0A> doesn't work or is not reliable= =2E=0D=0A>=20=0D=0A> > Is this understanding correct=3F=0D=0A> >=0D=0A> > 3= )The whole business relationships argument is especially confusing=0D=0A> >= to me since it seems that both Henning and James agree that ISPs=0D=0A> > = should not be required to have business relationships with VSPs. (I=0D=0A> = > don't think I've heard anyone in this thread argue against that=0D=0A> > = basic point).=0D=0A> >=0D=0A> > It is reasonable to say that a particular p= roposal is bad because=0D=0A> > it would require contractual relationships = between ISPs and VSPs,=0D=0A> > but so far I don't think I've heard James a= rgue in support of any=0D=0A> > particular proposal.=0D=0A>=20=0D=0A> I tho= ught James was an advocate of #3.=0D=0A>=20=0D=0A> What we seem to have an = issue with is the agreement on the=0D=0A> requirements, and this is causing= people not to agree on a solution.=0D=0A>=20=0D=0A> -andy=0D=0A>=20=0D=0A>= =20=0D=0A=0D=0A------------------------------------------------------------= ------------------------------------=0D=0AThis message is for the designate= d recipient only and may=0D=0Acontain privileged, proprietary, or otherwise= private information. =20=0D=0AIf you have received it in error, please not= ify the sender=0D=0Aimmediately and delete the original. Any unauthorized = use of=0D=0Athis email is prohibited.=0D=0A--------------------------------= ----------------------------------------------------------------=0D=0A[mf2]=0D= =0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu May 10 18:28:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmH7x-0006sC-5U; Thu, 10 May 2007 18:28:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmH7v-0006s7-Tq for ecrit@ietf.org; Thu, 10 May 2007 18:28:47 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmH7t-0003S5-Ie for ecrit@ietf.org; Thu, 10 May 2007 18:28:47 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1HmH7s-0005WC-5M; Thu, 10 May 2007 18:28:45 -0400 Message-ID: <46439CB1.509@bbn.com> Date: Thu, 10 May 2007 18:29:05 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] Location hiding: Consensus? References: <46437EFD.7090201@bbn.com> 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: a7d2e37451f7f22841e3b6f40c67db0f 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 Andy, I think you're right that we're disagreeing about requirements. With that in mind, here's another shot at requirements (below, and on the wiki page). I think there's pretty broad consensus on the Required Components and Requirements. But differences remaining on the Possible Requirements, and each of those could disqualify one or more solutions. --Richard Required components: 1. A mechanism to deliver to endpoints, at any time, 1. All emergency dial strings for their location 2. PSAP URIs (matched to service URNs) for all services available at their location 2. A mechanism to deliver endpoint location to PSAPs/emergency responders. 3. A mechanism by which a VSP can learn whether a URI is a PSAP URI Requirements: 1. MUST NOT require the ISP to give precise location to the endpoint. 2. MUST NOT require the ISP to give rough location to an unauthorized party. 3. A party in possession of a URL MAY be considered authorized. However, in this case, 1. The solution MUST specify which URLs are required to have this property, and 2. URLs MUST have a cryptographically random component with a specified minimum size 4. MUST NOT require a business/trust relationship between ISP and VSP 5. MUST NOT require a business/trust relationship between VSP and PSAPs 6. MAY require a business/trust relationship between ISP and PSAPs 7. MUST NOT require any particular structure for the emergency response network 8. MUST NOT require any particular geometric propertise of PSAP boundaries Possible requirements 1. MUST NOT require the ISP to give location of any granularity to the endpoint 2. MUST NOT require the use of a particular LoST resolver by the endpoint Desiderata: 1. Minimal effect on call setup latency 2. Minimal changes from existing protocols & architectures 3. Minimal difference between provisioning by-value and by-reference 4. Minimal changes to UA configuration mechanisms 5. Maintain separation of protocols for location configuration and mapping 6. Independence of protocol used by the UA for calling / session establishment Andrew Newton wrote: > > On May 10, 2007, at 4:22 PM, Matt Lepinski wrote: >> 1) I believe James began by stating that there are business >> requirements for location hiding, and that these are real >> requirements. I believe everyone participating in this thread agrees >> on that point. (Ignoring any value judgement about whether these >> requirements are good or evil) > > Well, I thought Henning disagreed with there being real business > requirements. > >> 2) James seems to believe that providing "fuzzed" location to the >> end-point is a bad idea. This would seem to be a fundamental source of >> disagreement with Henning who has supported sending "fuzzed" location >> to the end-point. >> >> Henning's argument seems to be that PSAP URI is already a form of >> "fuzzed" location that we're already providing, and James seems to be >> concerned with the access network provider being held accountable for >> providing "low quality" location. > > I am not a particular fan of fuzzing either. We've got little > deployment experience with this architecture and who knows what trouble > this will invite. > > And fuzzing adds fuel to the fire for those that say VoIP 9-1-1 doesn't > work or is not reliable. > >> Is this understanding correct? >> >> 3)The whole business relationships argument is especially confusing to >> me since it seems that both Henning and James agree that ISPs should >> not be required to have business relationships with VSPs. (I don't >> think I've heard anyone in this thread argue against that basic point). >> >> It is reasonable to say that a particular proposal is bad because it >> would require contractual relationships between ISPs and VSPs, but so >> far I don't think I've heard James argue in support of any particular >> proposal. > > I thought James was an advocate of #3. > > What we seem to have an issue with is the agreement on the requirements, > and this is causing people not to agree on a solution. > > -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 May 11 01:00:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmNEo-0003pA-6L; Fri, 11 May 2007 01:00:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmNEn-0003p5-Ht for ecrit@ietf.org; Fri, 11 May 2007 01:00:17 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmNEm-0004kF-PQ for ecrit@ietf.org; Fri, 11 May 2007 01:00:17 -0400 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l4B50Asq028315; Thu, 10 May 2007 23:00:11 -0600 Message-ID: <4643F859.9010301@ntt-at.com> Date: Thu, 10 May 2007 22:00:09 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ECRIT b , Brian Rosen , "James M. Polk" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fca741f5016e6ff607eaed2fd431d10d Cc: Subject: [Ecrit] Review: draft-ietf-ecrit-phonebcp-01.txt 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 Draft: draft-ietf-ecrit-phonebcp-01 Reviewer: Shida Schubert Review Date: 2007.05.10 Summary/General Comments: ---------------------------------------- - First of all thank you very much for putting this together.. I don't know why I waited so long to read this draft, it covers a lot of ground and gives you a very good idea on how SIP enabled device would interact with other entity to make emergency call work. I think it's in pretty good shape but needs some more work. - Introduction needs some text mentioning how this document provide the minimum primitives and recommended behavior each entity involved in an emergency call needs to support or comply. AFAIK, the document will also cover recommended behavior for LoST, Resolver etc. specific to an emergency call(providing default URI in case it can't inquire Forest Guide or other leaf node etc.) and it should be mentioned in an introduction as well. - Section 6.1 seems to lack the UA's behavior in case multiple location or multiple means of obtaining location exists(e.g. GPS, DHCP, L7-LCP). Technical Comments: ---------------------------------------- T1: Section 2, 4th paragraph. - 3rd bullet expects entity to get dialstring without the Service-URN. AFAIK it works the other way around. You provide the Service URN and you get dialstring in return. T2: Section 4.3. - I don't really see how location determined by network can be explicitly overridden by the location user enters. Even if device manages to override location information it obtained through DHCP, L7-LCP or LLDP-MED, same provider that provided the location can still insert the location by reference. - Also what do you mean by the last sentence on this section? What method? Account for what condition? T3: Section 4.4, paragraph 1, last sentence. - "In other words, the established VPN to Chicago from the device in Dallas MUST NOT overwrite the Dallas location for any reason especially an emergency call." > I don't think we have any specs to accomplish this "MUST NOT"? I see the value and when we consider VPN, it sure is a sounding requirement but do we have anything that we can provide to satisfy the "MUST NOT"? Problem is not only overwriting but the Dallas location should be used if there are multiple locations(e.g. proxy in Chicago may add by-reference location.) > I guess if UA is aware of the fact that it's connected to Dallas via VPN, and it could distinguish the location information it obtain from Dallas ISP/AP it could in fact flag the location it obtained with the "message-routed-on-this-uri" whether it be by-reference or by-value. T4: Section 4.4, paragraph 3. - I always thought that the location request is expected to take place if only when the device has no way to measure its location. If that's the case text should consider the fact that device may not be dependent on the Network for location configuration. T5: Section 4.5 - Emergency specific behavior and expectations surrounding location, I guess needs to be added to this section. e.g) by-value MUST NOT be encrypted using S/MIME etc. T6: Section 6.1, 1st bullet, last sentence. - sips URI being a MUST seems a bit too restrictive. RFC3261 compliant proxy is supposed to implement sips, but that's not how it is for UA. "SHOULD" here seems more reasonable. T7: Section 6.1, 3rd bullet. - You are mandating an AoR to be present when it may be possible that device can't set AoR. Where there is a chance that AoR may not be set and that's foreseen, shouldn't the strength be SHOULD not MUST or say something like "unless AoR can't be provided due to brabrabra.." T8: Section 6.1, 6th bullet - Neither P-A-ID or SIP IDentity are added at discretion of the UA, so this is a requirement for the administrative domain not that of a UA.. This bullet should be moved elsewhere. T9: Section 6.2, last bullet - I don't think we really want to change the location used for location based routing in midst of the routing. Also semantically would simple location based routing(local database using location to determine which next hop proxy it should route the call to) and location used for LoST resolution be the same thing? - Anyhow, if we want to allow mid-routing change of location used for location routing, I think you should add a text describing the implication. T10: Section 6.3, 1st sentence - AFAIK, LoST doesn't take location expressed by PIDF-LO does it? I thought it takes the location potion of the PIDF-LO but not the whole PIDF-LO. T11: Section 6.3, 2nd paragraph. - The mandate for LoST usage is "location support and LoST support" so the following text should say OLD: "User agents that can obtain location information MUST perform the mapping from location information to PSAP URI using [I-D.ietf-ecrit-lost ]. " NEW: "User agents that can obtain location information which support [I-D.ietf-ecrit-lost ]MUST perform the mapping from location information to PSAP URI using. > Question is what if UA doesn't support LoST? I guess it can't really forward the call to proxy to simply obtain PSAP URI could it? As it would probably end up making the actual emergency call... Clarifications Desirable: ---------------------------------------- C1: Section3 - In Introduction, it seems to focus on SIP devices though in section 3, the scope and expectation of devices supporting emergency call seems to not be limited to SIP devices. Is this document a BCP for SIP enabled phones and servers? If so I don't know if there is any value to leave it too flexible. C2: Section 4, 1st paragraph, last sentence. - Where is it a norm? IP? Current infrastructure? C3: Section 5, 4th paragraph, 2nd sentence. - What do yo mean? "The scheme includes a single emergency URN (urn:service:sos) and responder specific ones (urn:service:sos.police)".. Could you paraphrase this so I can understand what you are trying to state with this statement? Thank you.. Editorial Comments: ---------------------------------------- E1: Section 2, 4th paragraph, 5th bullet. OLD: It would determine the PSAP's URI by using the [I-D.ietf-ecrit-lost ] mapping server from the location provided NEW: It would determine the PSAP's URI with the location it obtained using the [I-D.ietf-ecrit-lost ] mapping server. E2: Section 2, 4th paragraph, last bullet. OLD: The call is established and common media streams opened. NEW: The call is established and common media streams open. E3: Section 2, last paragraph, 1st sentence. - "video" is missing. OLD: Best Current Practice for SIP user agents including handling of audio and real-time text [RFC4103 ]media detailed in [RFC4504 ] SHOULD be applied. NEW: Best Current Practice for SIP user agents including handling of audio, video and real-time text [RFC4103 ]media detailed in [RFC4504 ] SHOULD be applied. E4: Section 2, last paragraph, last sentence. - "as" is missing. OLD: This memo can be considered an addition to it for endpoints. NEW: This memo can be considered as an addition to it for endpoints. E5: Section 3, 1st paragraph, 2nd sentence. - There are 2 periods at the end of this sentence. E6: Section 3, 1st paragraph, 3rd sentence. OLD: In general, if a user could reasonably expect to be able to call for help with the device, NEW: In general, if a user could reasonably expect to make a call for help with the device, E7: Section 4, 2nd paragraph. - Use of "we" seems a bit odd. Who is WE? OLD: In Internet emergency calling, we "Determine" where the endpoint is located using a variety of measurement or wiretracing methods. We "Configure" endpoints with their own location. We "Map" the location to the URI to send the call to, and we "Convey" the location to the PSAP (and other elements) in the signaling. These topics are detailed in [I-D.ietf-ecrit-framework ]. NEW: In Internet emergency calling, we "Determine" where the endpoint is located using a variety of measurement or wiretracing methods. The endpoints are "Configured" with the measured or the obtained location . Location is "Mapped" to the URI where call is to be sent to, and "Conveyed" to the PSAP (and other elements) in the signaling. These topics are detailed in [I-D.ietf-ecrit-framework ]. E8: Section 4.1, 2nd paragraph, 2nd sentence. - Introduce the acronym LCP. OLD: To obtain location information, the endpoint can use a Location Configuration Protocol. NEW: To obtain location information, the endpoint can use a Location Configuration Protocol (LCP). E9: Section 4.3, 2nd last sentence. - demarc is an acronym so wouldn't it be DEMARC? E10: Section 5, 6th paragraph, OLD: This mapping is SHOULD performed at the endpoint device, but MAY be performed at an intermediate entity (such as a SIP proxy server) NEW: This mapping SHOULD be performed at the endpoint device, but MAY be performed at an intermediate entity (such as a SIP proxy server) E11: Section 5, 2nd last paragraph, last sentence. - Better keep the number format consistent. OLD: If the device roams to Paris, the home dialstring remains the same, "9-1-1", but the visited dialstring changes from 999 to "1-1-2". NEW: If the device roams to Paris, the home dialstring remains the same, "9-1-1", but the visited dialstring changes from "9-9-9" to "1-1-2". E12: Section 5, last paragraph, 2nd sentence. - No ")" OLD: [I-D.ietf-ecrit-lost ]) provides dialstrings for a given location and SHOULD be used by devices to learn the local (i.e. "visited" dialstrings. NEW: [I-D.ietf-ecrit-lost ]) provides dialstrings for a given location and SHOULD be used by devices to learn the local (i.e. "visited" dialstrings). E13: Section 6, 1st sentence. OLD: SIP signaling [RFC3261 ] is expected be supported by upgraded PSAPs. NEW: SIP signaling [RFC3261 ] is expected to be supported by upgraded PSAPs. E14: Section 6.1, 2nd bullet, 2nd sentence - "To" should be R-URI OLD: If the device cannot access a LoST server, the To: SHOULD be a service URN in the "sos" tree. If the device cannot do local dialstring interpretation, the Request-URI SHOULD be a dialstring URI NEW: If the device cannot access a LoST server, the Request-URI: SHOULD be a service URN in the "sos" tree. If the device cannot do local dialstring interpretation, the Request-URI SHOULD be a dialstring URI E15: Section 6.1, 7th bullet - How about something like this? OLD: A Contact header MUST be present (which might contain a GRUU [I-D.ietf-sip-gruu ]) to permit an immediate call-back to the specific device which placed the emergency call. NEW: A Contact header MUST be present with URI that's hopefully globally routable such as GRUU [I-D.ietf-sip-gruu ] to permit an immediate call-back to the specific device which placed the emergency call. E16: Sectino 6.1, 11th bullet - 11th bullet starts of with "if the device support loc-conv". Therefore it should come before bullet 10 > Change bullet 10 and 11. E17: Section 6.1, 10th bullet OLD: If the device's location is by-reference, a Geolocation: header [I-D.ietf-sip-location-conveyance ] MUST be present containing the URI of the PIDF-LO reference for that device. Whichever location is used for routing the message towards the PSAP or ESRP, even if there is only one, the Geolocation "message- routed-on-this-uri" header parameter SHOULD be added to the corresponding URI in the Geolocation header. NEW: If the device's location is by-reference, a Geolocation: header [I-D.ietf-sip-location-conveyance ] MUST be present containing the URI referencing the PIDF-LO for that device. E18: Section 6.1, 11th bullet OLD: if a device understands the SIP Location Conveyance [I-D.ietf-sip-location-conveyance ] extension and has its location available by value, it MUST include location either by-value or by-reference. If including by-value, the INVITE contains a Supported header with a "geolocation" option tag, and a "cid- URL" [RFC2396 ] as the value in the Geolocation header, indicating which message body part contains the PIDF-LO. If including the location by-reference, it includes the same Supported header with the "geolocation" option tag, and includes the URI to the PIDF-LO in a Geolocation header.[I-D.ietf-geopriv-pdif-lo-profile ] MUST be used. E19: Section 6.1 - Add a bullet for when UA does the LoST resolution and needs to mark the location it used for LoST. Following text is a suggestion. If the LoST resolution was done on UA, whichever location used for resolving PSAP or ESRP URI SHOULD have "message-routed-on-this-uri" header parameter appended to the corresponding URI in the Geolocation header. E20: Section 6.1, 15th bullet OLD: A UAC SHOULD include the Geolocation "inserted-by=endpoint" header parameter. NEW: A UAC SHOULD append the Geolocation "inserted-by=endpoint" header parameter to all the location UAC inserted. E21: Section 6.2, 1st bullet, 2nd point - "Insert a Geolocation header as per 10-12 above" would imply that proxy can add PIDF-LO into the message which violates RFC3261. Of course if it's B2BUA it's possible but I think you should focus on proxy here, so only reference 10 which talks about by-reference should be noted. I hope it helps. Thanks & Regards -- Shida Sven Schubert shida@ntt-at.com PHONE: (604) 762-5606 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 11 07:49:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmTd9-0007kH-Vc; Fri, 11 May 2007 07:49:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmTd8-0007kC-Im for ecrit@ietf.org; Fri, 11 May 2007 07:49:50 -0400 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmTd7-0004yl-JP for ecrit@ietf.org; Fri, 11 May 2007 07:49:50 -0400 Received: from ([139.76.131.31]) by aismt06p.bellsouth.com with SMTP id KP-AXPRN.21973607; Fri, 11 May 2007 07:49:26 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 11 May 2007 07:49:13 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 11 May 2007 07:49:13 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 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] Location hiding: Consensus? Date: Fri, 11 May 2007 07:49:12 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA03F4070D@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location hiding: Consensus? thread-index: AceTQQC0vMSE6CtgQESZRJ2g2bo5zQACAQhQAB2t7jA= References: <46437EFD.7090201@bbn.com> From: "Stark, Barbara" To: "Winterbottom, James" , "Matt Lepinski" X-OriginalArrivalTime: 11 May 2007 11:49:13.0680 (UTC) FILETIME=[655BC500:01C793C2] X-Spam-Score: 0.1 (/) X-Scan-Signature: 96e0f8497f38c15fbfc8f6f315bcdecb 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 think there might be a simpler way to handle the case of different "sos" services having different service boundaries. It seems to me the access network could get all the PSAP URIs from the LoST server (for a given location), and then have a simple mapping that says "if this set of PSAP URIs, then return this location (point or city/state/county/country)". The LIS can check once a day, or so, in non-real-time, to see if there have been any changes to PSAP boundaries that would invalidate the returned coarse location. But this doesn't happen very often. In the US, since the spread of 9-1-1, I don't see there being many (if any?) cases of differing boundaries (at the call center level) for different emergency services. There are definitely different boundaries for the responders, but that tends to be obscured at the call center level. If states implement a state-wide ESRN to handle routing to individual call centers, then there's really no problem. I also don't see a particular LIS being local to an overwhelming number of PSAPs, so the mapping of URI sets wouldn't be very large. I, too, would prefer Option 3, but I think Option 1 is do-able. Barbara -----Original Message----- From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]=20 Sent: Thursday, May 10, 2007 5:28 PM To: Matt Lepinski Cc: ECRIT Subject: RE: [Ecrit] Location hiding: Consensus? Matt, My real concern is that there is a huge difference for an access network provider between: 1) Getting a LoST server to return a bunch of URIs and corresponding service URNs for which it is designed to do based on location information provided. And 2) The access network asking the LoST server for the service boundaries of each emergency URN it knows about, performs intersection on these, and the providing the intersecting service boundary back to the end-point. Oh, and making sure that this location doesn't have more than 16 vertices and that it addresses any holes. Option is a practical solution to a real problem, 2 is quite frankly ridiculous. Cheers James > -----Original Message----- > From: Matt Lepinski [mailto:mlepinski@bbn.com] > Sent: Friday, 11 May 2007 6:22 AM > To: Winterbottom, James > Cc: Henning Schulzrinne; ECRIT > Subject: Re: [Ecrit] Location hiding: Consensus? >=20 > I'm really trying to understand the fundamental disagreement between=20 > James and Henning and I'm failing completely. > Any clarification of the following points would be greatly appreciated. >=20 > 1) I believe James began by stating that there are business requirements > for location hiding, and that these are real requirements. I believe=20 > everyone participating in this thread agrees on that point. (Ignoring=20 > any value judgement about whether these requirements are good or evil) >=20 > 2) James seems to believe that providing "fuzzed" location to the=20 > end-point is a bad idea. This would seem to be a fundamental source of > disagreement with Henning who has supported sending "fuzzed" location to > the end-point. >=20 > Henning's argument seems to be that PSAP URI is already a form of=20 > "fuzzed" location that we're already providing, and James seems to be=20 > concerned with the access network provider being held accountable for=20 > providing "low quality" location. >=20 > Is this understanding correct? >=20 > 3)The whole business relationships argument is especially confusing to > me since it seems that both Henning and James agree that ISPs should not > be required to have business relationships with VSPs. (I don't think=20 > I've heard anyone in this thread argue against that basic point). >=20 > It is reasonable to say that a particular proposal is bad because it=20 > would require contractual relationships between ISPs and VSPs, but so=20 > far I don't think I've heard James argue in support of any particular=20 > proposal. >=20 > Thanks for the clarification, sorry if I'm just being dense, > - Matt Lepinski :-> >=20 > Winterbottom, James wrote: >=20 > >Your responses miss the point in almost all cases. > > > >If you want to use IP to location database outside of my access network > >control please go ahead. I will certainly not be held accountable for > >providing you incorrect information, so I agree there may be=20 > >alternatives, but they are not my concern, and if you choose to use them > >on your head be it. > > > >If I give you a series of PSAP URIs and you choose to reverse engineer > >the service boundary, again that is your prerogative, and I can't stop > >you from doing it. It doesn't however, except in some very special=20 > >circumstances, tell you precisely where you are. > > > >As far as I can tell, LoST says currently, if you push in a location, it > >can push out a few things, one of which is the uri of a PSAP. It doesn't > >say that this MUST be the end-point, if it did, then the whole=20 > >retransmission-allowed discussion is moot. I have made no attempt to=20 > >change this premise. > > > >I simply do not understand your "business relationships" arguments. > >ECRIT is, as far as I am concerned, directed at routing emergency calls. > >It has always explicitly stated that how an end-point learns it location > >or otherwise is out of scope and a geopriv problem. So I put to you the > >following the scenario, and perhaps you can explain to me where the=20 > >"business relationship" impact comes into play. > > > >1) I ask the LIS for a location, it gives me back a bunch of dial=20 > >strings, a corresponding bunch of PSAP URIs, and a location reference. > >(so far no business relationship). > > > >2) I make a call through my VSP in Sierra Leone (UAC to VSP relationship > >but this has always been agreed to). > > > >3a) VSP routes call to PSAP (I have a monthly calling plan), PSAP=20 > >answers call and uses reference (no business relationship) > > > >3b) VSP wants to check the URI, it uses a yet to be built LoST interface > >that does URI to service mapping, and either bills me, or pushes the=20 > >call to the PSAP (no business relationship). > > > >This is all in scope for ECRIT, and seems fine to me. > > > >If I want to use location for other servic network provider should=20 > >not be able to charge for this. are you saying that they should not=20 > >be allowed to charge for this? > > > >Cheers > >James > > > > > > > > > > > >>-----Original Message----- > >>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >>Sent: Thursday, 10 May 2007 12:32 PM > >>To: Winterbottom, James > >>Cc: ECRIT > >>Subject: Re: [Ecrit] Location hiding: Consensus? > >> > >> > >>On May 9, 2007, at 10:06 PM, Winterbottom, James wrote: > >> > >> > >> > >>>Firstly, without the business model this is not going happen=20 > >>>alternatives will be found, and they will likely be local > >>> > >>> > >derivatives. > > > > > >>>Business requirements are requirements none the less and to ignore=20 > >>>this fact is silly. Two major carriers on this list have indicated=20 > >>>that they will deploy this kind of solution, we can bury our heads=20 > >>>in the sand, or we can solve it. See below that I think any kind of > >>>providing > >>> > >>> > >partial > > > > > >>>location is a bad idea. > >>> > >>> > >>> > >>If you recall the earlier discussion, we had already agreed that > >>revealing the PSAP URL effectively reveals the PSAP coverage area, > >>since this is generally public. Thus, trying to hide anything below > >>that level is pointless, even if you don't believe in the fact that > >>IP address-based location is, in most cases, at least as precise. > >> > >> > >> > >> > >> > >>>I don't really see ISPs necessarily competing with VSPs, they may in > >>>some cases but they certainly don't in others. The example is > >>> > >>> > >exactly > > > > > >>>the Brian's Sierra Leone case, how is my home VSP in Sierra Leone > >>>competing with my the ISP serving my hotel in Minneapolis? > >>> > >>> > >>They may not be, but the solution has to work even if they are > >>competing. Let's say I set up a VSP that believes that location > >>information should be freely given to my customers. You are now > >>prohibiting me from serving my customers if I don't sign your NDA? > >>How would you enforce that the Sierra Leonian VSP doesn't hand out > >>location information to their customers? Should every ISP sign an NDA > >>with every VSP? > >> > >>I'm sorry, > >> > >> > >ress if we re-argue the > > > > > >>core ECRIT assumptions for each problem. The 'no business > >>relationship' assumption has been in our requirements document from > >>the very beginning. It might even be in the charter discussion. > >> > >> > >> > >> > >>>If I provide an end-point a fuzzed location how do they know what > >>>it is > >>>restricted to? If it is good enough for a LoST server to then > >>> > >>> > >provide > > > > > >>>them with a PSAP URI, how do you ensure without a doubt that it > >>> > >>> > >isn't > > > > > >>>good enough to get them to a Pizza hut? How do you ensure that the > >>>centroid will get them to the right Pizza hut? How do you stop thw > >>>wrong > >>>pizza hut from getting really annoyed because they keeping getting > >>>incorrect calls? The list goes on. Not to mention, that a LIS that > >>>did > >>>not previously need to know anything about service boundaries now > >>>needs > >>>to compute them. Please read this as "I really really really hate > >>> > >>> > >any > > > > > >>>solution that requires a LIS or LIS operator to do this". > >>> > >>> > >>ECRIT is solving the emergency calling problem. Besides, the same > >>problem will occur with any non-precise information, whether this is > >>cell-sector or this artificially fuzzed data. As far as I can tell, > >>you have not been objecting to delivering cell-sector information to > >>end users. > >> > >> > >> > >> > >>>I would also like to stress that I think that this is as much a > >>>GeoPriv > >>>problem as it is an ECRIT problem. > >>> > >>> > >>> > >>I'm sure that adding another working group is going to help us make > >>progress... > >> > >> > >> > >>>Cheers > >>>James > >>> > >>> > >>> > > > >----------------------------------------------------------------------- -- > ----------------------- > >This message is for the designated recipient only and may > >contain privileged, proprietary, or otherwise private information. > >If you have received it in error, please notify the sender > >immediately and delete the original. Any unauthorized use of > >this email is prohibited. > >----------------------------------------------------------------------- -- > ----------------------- > >[m > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > >=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 ***** 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. GA625 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 11 10:56:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmWXK-0002br-Ac; Fri, 11 May 2007 10:56:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmWXI-0002bh-LL for ecrit@ietf.org; Fri, 11 May 2007 10:56:00 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmWXH-0001o2-CF for ecrit@ietf.org; Fri, 11 May 2007 10:56:00 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HmWWg-0006Cl-IK; Fri, 11 May 2007 09:55:23 -0500 From: "Brian Rosen" To: , "'ECRIT'" References: <46416F89.4010606@ntt-at.com> Date: Fri, 11 May 2007 10:55:22 -0400 Message-ID: <000f01c793dc$7bb0eff0$e4003c0a@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.3028 In-Reply-To: <46416F89.4010606@ntt-at.com> Thread-Index: AceSBkBTxmpsSVIWT2KP/gqo8yZdygAANw2w X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Subject: [Ecrit] RE: LoST returning location used?? X-BeenThere: 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 can't follow this email. If the UA (foolishly in my opinion) puts more than one location in an INVITE, and does not do the routing, then the proxy is going to pick one, and which one it picks will, indeed, not be known to the UA. Actually, if there is an error, the "loop back" mechanism we are discussing for -conveyance would return the location that was found to be in error, and it might be marked "used for routing". I fail to see a problem. If the UA wishes to not be confused, it should not put more than one location on the INVITE. Now, the UA may put a location in the INVITE, and then the network may put another on. The UA may not know that one. I don't see a problem with that either, and the loopback is designed to make sure that the entity putting the location on knows which one the error is referring to. Brian > -----Original Message----- > From: Shida Schubert [mailto:shida@ntt-at.com] > Sent: Wednesday, May 09, 2007 2:52 AM > To: ECRIT > Cc: Henning Schulzrinne; Brian Rosen; James M. Polk > Subject: LoST returning location used?? > > > I might have overlooked something completely but while I was > reviewing the framework document the following question came up. > > The framework document expects some sort of flagging on > the location to indicate which location was used to do location > based routing (LoST & non-LoST) when there are multiple > location information in the message. > > According to the LoST-05, the client can insert multiple > location information but which location was used for the actual > resolution is not returned to the client. One may guess or sometime > clearly find out which location was used, simply analyzing the > "ServiceBoundary" but according to the debate going on right > now it doesn't seem so simple after all. > > If the client can't tell which location was actually used for routing, > how would the client, let's say a proxy using the "used-for-routing" > parameter indicate which location was actually used for routing the > call. > > The framework also expects the entity on the signaling path > acting as a LoST client to use the same location information flagged > with "used-for-routing", would it restrict the LoST client to include > only the flagged location information for LoST query once it's > flagged using "used-for-routing"?? > > Regards > Shida _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 11 12:17:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmXo2-0004I4-5y; Fri, 11 May 2007 12:17:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmXo0-0004Hx-TZ for ecrit@ietf.org; Fri, 11 May 2007 12:17:20 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmXo0-0001x7-IP for ecrit@ietf.org; Fri, 11 May 2007 12:17:20 -0400 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l4BGH3bL008977; Fri, 11 May 2007 10:17:04 -0600 Message-ID: <464496FF.2060905@ntt-at.com> Date: Fri, 11 May 2007 09:17:03 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Brian Rosen References: <46416F89.4010606@ntt-at.com> <000f01c793dc$7bb0eff0$e4003c0a@cis.neustar.com> In-Reply-To: <000f01c793dc$7bb0eff0$e4003c0a@cis.neustar.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: 'ECRIT' Subject: [Ecrit] Re: LoST returning location used?? 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 Hi Brian; Let me try to paraphrase my concern. Let's assume that UA obtains 3 locations, 1 from GPS, 1 from DHCP and 1 from L7-LCP. According to the current LoST spec, LoST client can set as many location information as it wants as long as it is of different profile. If the location UA obtains are all of different profiles it can include all 3 of them. What I thought the spec said was that LoST doesn't return, which location it used to resolve the URI that it includes in the response. I thought that one can only guess from the data under the . But as I looked at the LoST-05, I realized that provides profile and with that UA can match the profile in the request and that of a and figure out the location used for LoST resolution. So problem wasn't as bad as I initially believed. But it is still somewhat concerning when is returned. AFAIK doesn't include the profile which imposes LoST client to look up the to figure out which location in LoST request was used to resolve the PSAP URI. Anyhow why I had the initial concern was due to UA not knowing which location needs to be appended with 'message-routed-on-this-uri" parameter if profile is not indicated. As I found out re-reviewing the LoST spec, it's not a problem when ServiceBoundary is returned by-value but can be problematic when returned by-reference. I hope I managed to clarify my concern. Regards Shida Brian Rosen wrote: > I can't follow this email. > > If the UA (foolishly in my opinion) puts more than one location in an > INVITE, and does not do the routing, then the proxy is going to pick one, > and which one it picks will, indeed, not be known to the UA. > > Actually, if there is an error, the "loop back" mechanism we are discussing > for -conveyance would return the location that was found to be in error, and > it might be marked "used for routing". > > I fail to see a problem. If the UA wishes to not be confused, it should not > put more than one location on the INVITE. > > Now, the UA may put a location in the INVITE, and then the network may put > another on. The UA may not know that one. I don't see a problem with that > either, and the loopback is designed to make sure that the entity putting > the location on knows which one the error is referring to. > > Brian > > >> -----Original Message----- >> From: Shida Schubert [mailto:shida@ntt-at.com] >> Sent: Wednesday, May 09, 2007 2:52 AM >> To: ECRIT >> Cc: Henning Schulzrinne; Brian Rosen; James M. Polk >> Subject: LoST returning location used?? >> >> >> I might have overlooked something completely but while I was >> reviewing the framework document the following question came up. >> >> The framework document expects some sort of flagging on >> the location to indicate which location was used to do location >> based routing (LoST & non-LoST) when there are multiple >> location information in the message. >> >> According to the LoST-05, the client can insert multiple >> location information but which location was used for the actual >> resolution is not returned to the client. One may guess or sometime >> clearly find out which location was used, simply analyzing the >> "ServiceBoundary" but according to the debate going on right >> now it doesn't seem so simple after all. >> >> If the client can't tell which location was actually used for routing, >> how would the client, let's say a proxy using the "used-for-routing" >> parameter indicate which location was actually used for routing the >> call. >> >> The framework also expects the entity on the signaling path >> acting as a LoST client to use the same location information flagged >> with "used-for-routing", would it restrict the LoST client to include >> only the flagged location information for LoST query once it's >> flagged using "used-for-routing"?? >> >> Regards >> Shida >> > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 11 13:34:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmZ0z-0001Rp-Ro; Fri, 11 May 2007 13:34:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmZ0z-0001Rk-6W for ecrit@ietf.org; Fri, 11 May 2007 13:34:49 -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 1HmZ0x-0001WB-SA for ecrit@ietf.org; Fri, 11 May 2007 13:34:49 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Fri, 11 May 2007 13:34:47 -0400 id 01588152.4644A937.00004EC4 In-Reply-To: <464496FF.2060905@ntt-at.com> References: <46416F89.4010606@ntt-at.com> <000f01c793dc$7bb0eff0$e4003c0a@cis.neustar.com> <464496FF.2060905@ntt-at.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7AF39455-A4C5-4116-9B49-89BD6A5D3FFA@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Re: LoST returning location used?? Date: Fri, 11 May 2007 13:34:46 -0400 To: shida@ntt-at.com X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac 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 Shida, We can add the profile identifier to the . That's a good catch. However, your scenario can gateway into another use case. There is nothing that says that GPS, DHCP, and L7-LCP cannot deliver location information of the same type of profile, in this case geodetic-2d. If the seeker knows they are all of the same profile type, it should query on each set of location information separately. In the case where the seeker doesn't know the location profile, the profile id returned in or will not help it out too much. Perhaps we ought to have a client-assigned id as well, so the client can tell which location was used in this case. -andy On May 11, 2007, at 12:17 PM, Shida Schubert wrote: > > Hi Brian; > > Let me try to paraphrase my concern. > > Let's assume that UA obtains 3 locations, 1 from GPS, 1 from DHCP > and 1 from L7-LCP. > > According to the current LoST spec, LoST client can set as many > location > information as it wants as long as it is of different profile. If > the location UA > obtains are all of different profiles it can include all 3 of them. > > What I thought the spec said was that LoST doesn't return, which > location it > used to resolve the URI that it includes in the response. I thought > that one can > only guess from the data under the . But as I > looked at the > LoST-05, I realized that provides profile and > with that > UA can match the profile in the request and that of a > and > figure out the location used for LoST resolution. So problem wasn't > as bad as I > initially believed. But it is still somewhat concerning when > > is returned. AFAIK doesn't include the > profile > which imposes LoST client to look up the > to figure > out which location in LoST request was used to resolve the PSAP URI. > > Anyhow why I had the initial concern was due to UA not knowing > which location > needs to be appended with 'message-routed-on-this-uri" parameter > if profile is not > indicated. As I found out re-reviewing the LoST spec, it's not a > problem when > ServiceBoundary is returned by-value but can be problematic when > returned > by-reference. > I hope I managed to clarify my concern. > > Regards > Shida > > > Brian Rosen wrote: >> I can't follow this email. >> >> If the UA (foolishly in my opinion) puts more than one location in an >> INVITE, and does not do the routing, then the proxy is going to >> pick one, >> and which one it picks will, indeed, not be known to the UA. >> Actually, if there is an error, the "loop back" mechanism we are >> discussing >> for -conveyance would return the location that was found to be in >> error, and >> it might be marked "used for routing". >> >> I fail to see a problem. If the UA wishes to not be confused, it >> should not >> put more than one location on the INVITE. >> >> Now, the UA may put a location in the INVITE, and then the network >> may put >> another on. The UA may not know that one. I don't see a problem >> with that >> either, and the loopback is designed to make sure that the entity >> putting >> the location on knows which one the error is referring to. >> >> Brian >> >> >>> -----Original Message----- >>> From: Shida Schubert [mailto:shida@ntt-at.com] >>> Sent: Wednesday, May 09, 2007 2:52 AM >>> To: ECRIT >>> Cc: Henning Schulzrinne; Brian Rosen; James M. Polk >>> Subject: LoST returning location used?? >>> >>> >>> I might have overlooked something completely but while I was >>> reviewing the framework document the following question came up. >>> >>> The framework document expects some sort of flagging on >>> the location to indicate which location was used to do location >>> based routing (LoST & non-LoST) when there are multiple >>> location information in the message. >>> >>> According to the LoST-05, the client can insert multiple >>> location information but which location was used for the actual >>> resolution is not returned to the client. One may guess or sometime >>> clearly find out which location was used, simply analyzing the >>> "ServiceBoundary" but according to the debate going on right >>> now it doesn't seem so simple after all. >>> >>> If the client can't tell which location was actually used for >>> routing, >>> how would the client, let's say a proxy using the "used-for-routing" >>> parameter indicate which location was actually used for routing the >>> call. >>> >>> The framework also expects the entity on the signaling path >>> acting as a LoST client to use the same location information flagged >>> with "used-for-routing", would it restrict the LoST client to >>> include >>> only the flagged location information for LoST query once it's >>> flagged using "used-for-routing"?? >>> >>> Regards >>> Shida >>> >> >> >> > > > _______________________________________________ > 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 May 14 17:31:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hni8z-0000kI-6x; Mon, 14 May 2007 17:31:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hni8y-0000kD-Ee for ecrit@ietf.org; Mon, 14 May 2007 17:31:48 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hni8x-0003lu-Uc for ecrit@ietf.org; Mon, 14 May 2007 17:31:48 -0400 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l4ELVcUA031702; Mon, 14 May 2007 15:31:39 -0600 Message-ID: <4648D534.2010605@ntt-at.com> Date: Mon, 14 May 2007 14:31:32 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] Re: LoST returning location used?? References: <46416F89.4010606@ntt-at.com> <000f01c793dc$7bb0eff0$e4003c0a@cis.neustar.com> <464496FF.2060905@ntt-at.com> <7AF39455-A4C5-4116-9B49-89BD6A5D3FFA@hxr.us> In-Reply-To: <7AF39455-A4C5-4116-9B49-89BD6A5D3FFA@hxr.us> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Cc: 'ECRIT' 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 Andy, For the use-cases you provided, I thought client would be able to match each LoST query/response even when 3 requests are sent simultaneously (Doesn't HTTP provide a way to identify the request to response?) so I didn't think client will have an issue of not being able to match the location used in request and that of response. Although some may question which location/ mapping is to be used when all 3 requests return response with PSAP URIs almost simultaneously(Probably depends on the local policy, location preference etc.). I may be missing something but seeker not understanding the location profile doesn't seem to be an issue in itself. As long as client(seeker) can match the location used in request to location used in response. But again looking at RFC 4119, RFC3825 and seeing the fact that they seem to not carry the profile information, the question comes to my mind as to how seeker sets the profile to the in LoST request. If that's what you are implying, I share your concern. As I did a quick scan on the 2 RFCs mentioned above, I did not see the profile to be provided, which seems mandatory to set in the LoST in case LoST server is handling multiple locations in single LoST query. Regards Shida Andrew Newton wrote: > Shida, > > We can add the profile identifier to the . > That's a good catch. > > However, your scenario can gateway into another use case. There is > nothing that says that GPS, DHCP, and L7-LCP cannot deliver location > information of the same type of profile, in this case geodetic-2d. If > the seeker knows they are all of the same profile type, it should > query on each set of location information separately. In the case > where the seeker doesn't know the location profile, the profile id > returned in or will not > help it out too much. Perhaps we ought to have a client-assigned id > as well, so the client can tell which location was used in this case. > > -andy > > > On May 11, 2007, at 12:17 PM, Shida Schubert wrote: > >> >> Hi Brian; >> >> Let me try to paraphrase my concern. >> >> Let's assume that UA obtains 3 locations, 1 from GPS, 1 from DHCP >> and 1 from L7-LCP. >> >> According to the current LoST spec, LoST client can set as many location >> information as it wants as long as it is of different profile. If the >> location UA >> obtains are all of different profiles it can include all 3 of them. >> >> What I thought the spec said was that LoST doesn't return, which >> location it >> used to resolve the URI that it includes in the response. I thought >> that one can >> only guess from the data under the . But as I looked >> at the >> LoST-05, I realized that provides profile and with >> that >> UA can match the profile in the request and that of a >> and >> figure out the location used for LoST resolution. So problem wasn't >> as bad as I >> initially believed. But it is still somewhat concerning when >> >> is returned. AFAIK doesn't include the >> profile >> which imposes LoST client to look up the >> to figure >> out which location in LoST request was used to resolve the PSAP URI. >> >> Anyhow why I had the initial concern was due to UA not knowing which >> location >> needs to be appended with 'message-routed-on-this-uri" parameter if >> profile is not >> indicated. As I found out re-reviewing the LoST spec, it's not a >> problem when >> ServiceBoundary is returned by-value but can be problematic when >> returned >> by-reference. >> I hope I managed to clarify my concern. >> >> Regards >> Shida >> >> >> Brian Rosen wrote: >>> I can't follow this email. >>> >>> If the UA (foolishly in my opinion) puts more than one location in an >>> INVITE, and does not do the routing, then the proxy is going to pick >>> one, >>> and which one it picks will, indeed, not be known to the UA. >>> Actually, if there is an error, the "loop back" mechanism we are >>> discussing >>> for -conveyance would return the location that was found to be in >>> error, and >>> it might be marked "used for routing". >>> >>> I fail to see a problem. If the UA wishes to not be confused, it >>> should not >>> put more than one location on the INVITE. >>> >>> Now, the UA may put a location in the INVITE, and then the network >>> may put >>> another on. The UA may not know that one. I don't see a problem >>> with that >>> either, and the loopback is designed to make sure that the entity >>> putting >>> the location on knows which one the error is referring to. >>> >>> Brian >>> >>> >>>> -----Original Message----- >>>> From: Shida Schubert [mailto:shida@ntt-at.com] >>>> Sent: Wednesday, May 09, 2007 2:52 AM >>>> To: ECRIT >>>> Cc: Henning Schulzrinne; Brian Rosen; James M. Polk >>>> Subject: LoST returning location used?? >>>> >>>> >>>> I might have overlooked something completely but while I was >>>> reviewing the framework document the following question came up. >>>> >>>> The framework document expects some sort of flagging on >>>> the location to indicate which location was used to do location >>>> based routing (LoST & non-LoST) when there are multiple >>>> location information in the message. >>>> >>>> According to the LoST-05, the client can insert multiple >>>> location information but which location was used for the actual >>>> resolution is not returned to the client. One may guess or sometime >>>> clearly find out which location was used, simply analyzing the >>>> "ServiceBoundary" but according to the debate going on right >>>> now it doesn't seem so simple after all. >>>> >>>> If the client can't tell which location was actually used for >>>> routing, >>>> how would the client, let's say a proxy using the "used-for-routing" >>>> parameter indicate which location was actually used for routing the >>>> call. >>>> >>>> The framework also expects the entity on the signaling path >>>> acting as a LoST client to use the same location information flagged >>>> with "used-for-routing", would it restrict the LoST client to include >>>> only the flagged location information for LoST query once it's >>>> flagged using "used-for-routing"?? >>>> >>>> Regards >>>> Shida >>>> >>> >>> >>> >> >> >> _______________________________________________ >> 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 May 14 18:31:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnj4T-0001gd-Ge; Mon, 14 May 2007 18:31:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnj4S-0001gY-9e for ecrit@ietf.org; Mon, 14 May 2007 18:31:12 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnj4S-00070q-0J for ecrit@ietf.org; Mon, 14 May 2007 18:31:12 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JI100GBQYJZKW@usaga01-in.huawei.com> for ecrit@ietf.org; Mon, 14 May 2007 15:31:11 -0700 (PDT) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JI100FCPYJXMI@usaga01-in.huawei.com> for ecrit@ietf.org; Mon, 14 May 2007 15:31:11 -0700 (PDT) Date: Mon, 14 May 2007 17:29:20 -0500 From: Spencer Dawkins Subject: Re: [Ecrit] Re: LoST returning location used?? To: 'ECRIT' Message-id: <2b4501c79677$51586290$6601a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=UTF-8; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <46416F89.4010606@ntt-at.com> <000f01c793dc$7bb0eff0$e4003c0a@cis.neustar.com> <464496FF.2060905@ntt-at.com> <7AF39455-A4C5-4116-9B49-89BD6A5D3FFA@hxr.us> <4648D534.2010605@ntt-at.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a X-BeenThere: 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, Shida, From: "Shida Schubert" > Andy, > > For the use-cases you provided, I thought client would be able to match > each LoST query/response even when 3 requests are sent simultaneously > (Doesn't HTTP provide a way to identify the request to response?) so I Two choices in HTTP/1.1, persistent TCP connections (SHOULD) and "per-object" TCP connections (original mechanism). For persistent TCP connections - responses must be returned in the order that requests are received. Pipelining is allowed, but if you send three requests off, you get the response to the first request, then the second, then the third. For "per-object" TCP connections - ("Connection: close") - the server gets a request, sends the response, and closes the TCP connection. This gives you ghastly performance for small transfers (because you do SYN/SYN-ACK/ACK before each object, and FIN/FIN-ACK in each direction after each object. There's also no way for the client to control which strategy a server uses. Details in RFC 2616, Section 8.1 ("connections"), especially 8.1. Spencer > didn't > think client will have an issue of not being able to match the location > used > in request and that of response. Although some may question which > location/ > mapping is to be used when all 3 requests return response with PSAP URIs > almost simultaneously(Probably depends on the local policy, location > preference > etc.). > > I may be missing something but seeker not understanding the location > profile > doesn't seem to be an issue in itself. As long as client(seeker) can match > the location > used in request to location used in response. But again looking at RFC > 4119, > RFC3825 and seeing the fact that they seem to not carry the profile > information, > the question comes to my mind as to how seeker sets the profile to the > > in LoST request. If that's what you are implying, I share your concern. As > I did a quick > scan on the 2 RFCs mentioned above, I did not see the profile to be > provided, > which seems mandatory to set in the LoST in case LoST server is handling > multiple > locations in single LoST query. > > Regards > Shida _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 15 00:20:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnoWi-0005te-2A; Tue, 15 May 2007 00:20:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnoWh-0005tV-0U for ecrit@ietf.org; Tue, 15 May 2007 00:20:43 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnoWg-0008Nn-Kf for ecrit@ietf.org; Tue, 15 May 2007 00:20:42 -0400 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l4F4KdHT005169; Mon, 14 May 2007 22:20:39 -0600 Message-ID: <46493517.70709@ntt-at.com> Date: Mon, 14 May 2007 21:20:40 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Spencer Dawkins Subject: Re: [Ecrit] Re: LoST returning location used?? References: <46416F89.4010606@ntt-at.com> <000f01c793dc$7bb0eff0$e4003c0a@cis.neustar.com> <464496FF.2060905@ntt-at.com> <7AF39455-A4C5-4116-9B49-89BD6A5D3FFA@hxr.us> <4648D534.2010605@ntt-at.com> <2b4501c79677$51586290$6601a8c0@china.huawei.com> In-Reply-To: <2b4501c79677$51586290$6601a8c0@china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: 'ECRIT' 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 Hi Spencer; Thanks for the little tutorial.. Seeing what you have noted below, it looks like LoST client will always be able to match the request to response, and thus if 3 requests all containing location with same profile (e.g "geodetic-2d") are sent and only one of the request is returned with the response with a resolution(PSAP URI etc.), the LoST client will be able to match which request received a response, and thus able to mark the proper location information with "message-routed-on-this-uri" parameter. What's unclear to me and concerning to me is 1. Profile doesn't seem to be provided in the LCP that client uses to obtain information (Like I said before, I might have overlooked something..), if so how would the UA declare which information is based on profile X in LoST request? 2. What to do if requests sent are returned with different Boundary and PSAP URIs? I think we may want to set some guidelines for this in phone-bcp as I understand everything that is related to location-conveyance + emergency is going into phone-bcp. Regards Shida Spencer Dawkins wrote: > Hi, Shida, > > From: "Shida Schubert" > >> Andy, >> >> For the use-cases you provided, I thought client would be able to match >> each LoST query/response even when 3 requests are sent simultaneously >> (Doesn't HTTP provide a way to identify the request to response?) so I > > Two choices in HTTP/1.1, persistent TCP connections (SHOULD) and > "per-object" TCP connections (original mechanism). > > For persistent TCP connections - responses must be returned in the > order that requests are received. Pipelining is allowed, but if you > send three requests off, you get the response to the first request, > then the second, then the third. > > For "per-object" TCP connections - ("Connection: close") - the server > gets a request, sends the response, and closes the TCP connection. > This gives you ghastly performance for small transfers (because you do > SYN/SYN-ACK/ACK before each object, and FIN/FIN-ACK in each direction > after each object. > > There's also no way for the client to control which strategy a server > uses. > > Details in RFC 2616, Section 8.1 ("connections"), especially 8.1. > > Spencer > >> didn't >> think client will have an issue of not being able to match the >> location used >> in request and that of response. Although some may question which >> location/ >> mapping is to be used when all 3 requests return response with PSAP URIs >> almost simultaneously(Probably depends on the local policy, location >> preference >> etc.). >> >> I may be missing something but seeker not understanding the location >> profile >> doesn't seem to be an issue in itself. As long as client(seeker) can >> match the location >> used in request to location used in response. But again looking at >> RFC 4119, >> RFC3825 and seeing the fact that they seem to not carry the profile >> information, >> the question comes to my mind as to how seeker sets the profile to >> the >> in LoST request. If that's what you are implying, I share your >> concern. As I did a quick >> scan on the 2 RFCs mentioned above, I did not see the profile to be >> provided, >> which seems mandatory to set in the LoST in case LoST server is >> handling multiple >> locations in single LoST query. >> >> Regards >> Shida > > > > _______________________________________________ > 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 May 15 09:49:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnxOr-0003Xv-0T; Tue, 15 May 2007 09:49:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnxOp-0003Xl-8O for ecrit@ietf.org; Tue, 15 May 2007 09:49:11 -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 1HnxOp-0006M4-0K for ecrit@ietf.org; Tue, 15 May 2007 09:49:11 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 15 May 2007 09:49:10 -0400 id 01588374.4649BA56.0000352F In-Reply-To: <46493517.70709@ntt-at.com> References: <46416F89.4010606@ntt-at.com> <000f01c793dc$7bb0eff0$e4003c0a@cis.neustar.com> <464496FF.2060905@ntt-at.com> <7AF39455-A4C5-4116-9B49-89BD6A5D3FFA@hxr.us> <4648D534.2010605@ntt-at.com> <2b4501c79677$51586290$6601a8c0@china.huawei.com> <46493517.70709@ntt-at.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2F2C2B75-4385-4439-8BDB-BB3FBAB4C48F@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Re: LoST returning location used?? Date: Tue, 15 May 2007 09:49:03 -0400 To: shida@ntt-at.com X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 Shida, Spencer, My comments are in-line... On May 15, 2007, at 12:20 AM, Shida Schubert wrote: > Seeing what you have noted below, it looks like LoST client > will always be able to match the request to response, and thus if > 3 requests all containing location with same profile (e.g > "geodetic-2d") > are sent and only one of the request is returned with the response > with > a resolution(PSAP URI etc.), the LoST client will be able to match > which request received a response, and thus able to mark the proper > location information with "message-routed-on-this-uri" parameter. That is correct. Requests sent in different HTTP requests can be easily matched to their corresponding HTTP responses. However, the LoST schema allows each XML instance to contain multiple sets of location information. And if the client does not understand location profiles, it may not understand which location information is being used. That is why I suggested a client-assigned request-scope unique identifier for each set of location information found in a particular LoST XML instance. > What's unclear to me and concerning to me is > 1. Profile doesn't seem to be provided in the LCP that client uses > to obtain information (Like I said before, I might have > overlooked > something..), if so how would the UA declare which information is > based on profile X in LoST request? You are correct. I suggested one method to handle this. But we seem to have competing ideas: either seekers know about the type of location information they are using, or they don't. But it seems we have a situation now where we want it both ways. > 2. What to do if requests sent are returned with different > Boundary and PSAP URIs? I think we may want to set some > guidelines > for this in phone-bcp as I understand everything that is > related to > location-conveyance + emergency is going into phone-bcp. Yes, that's the issue with using multiple HTTP requests for multiple location information sets that essentially point to the same place. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu May 17 17:55:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Honw0-0000jn-EY; Thu, 17 May 2007 17:54:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Honvy-0000jd-NB for ecrit@ietf.org; Thu, 17 May 2007 17:54:54 -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 1Honvx-0003Dm-CF for ecrit@ietf.org; Thu, 17 May 2007 17:54:54 -0400 Received: from machine77.Level3.com (qfe4.f10212-07.adc1.oss.level3.com [10.2.1.230]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id l4HLsqBl012145 for ; Thu, 17 May 2007 21:54:52 GMT Received: from machine77.Level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id CA122124809 for ; Thu, 17 May 2007 21:54:51 +0000 (GMT) Received: from IDC1EXC0001B.corp.global.level3.com (idc1exc0001b.corp.global.level3.com [10.1.9.25]) by scanner5.level3.com (Postfix) with SMTP id 7857B124805 for ; Thu, 17 May 2007 21:54:51 +0000 (GMT) Received: from idc1exc0004.corp.global.level3.com ([10.1.9.15]) by IDC1EXC0001B.corp.global.level3.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 May 2007 15:54:50 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 17 May 2007 15:54:50 -0600 Message-ID: <8EAEBD84136584449B84AC177199EC4902F94A45@idc1exc0004.corp.global.level3.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: i2 NOmadic 911 using TDM interconnect thread-index: AceYzf4wMAVdzJYeTfCnjI0Nn8ghZA== From: "Karihaloo, Ujjval" To: X-OriginalArrivalTime: 17 May 2007 21:54:50.0857 (UTC) FILETIME=[FE7B7590:01C798CD] X-Spam-Score: 0.1 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Subject: [Ecrit] i2 NOmadic 911 using TDM interconnect X-BeenThere: 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="===============0059915930==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0059915930== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C798CD.FE959785" This is a multi-part message in MIME format. ------_=_NextPart_001_01C798CD.FE959785 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi All, =20 Is there any guidance on how to do an SS7 handoff to a Carrier for a Nomadic 911 Call flow? I understand i2 call flow requires an ESRN and ESQK to be carried as called and calling numbers, where do we actually populate the Actual ANI in the IAM message whilst handing the 911 Call off to a Carrier (who then hands it off to a PSAP)? =20 =20 Ujjval Karihaloo =20 ------_=_NextPart_001_01C798CD.FE959785 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi All,

 

     Is there any guidance on how = to do an SS7 handoff to a Carrier for a Nomadic 911 Call flow? I understand i2 call flow requires = an ESRN and ESQK to be carried as called and calling numbers, where do we = actually populate the Actual ANI in the IAM message whilst handing the 911 Call = off to a Carrier (who then hands it off to a PSAP)?

 

 

Ujjval = Karihaloo

 

------_=_NextPart_001_01C798CD.FE959785-- --===============0059915930== 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 --===============0059915930==-- From ecrit-bounces@ietf.org Thu May 17 18:23:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HooNK-0005Dy-NL; Thu, 17 May 2007 18:23:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HooNJ-0005A2-Nd for ecrit@ietf.org; Thu, 17 May 2007 18:23:09 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HooNI-0002dw-5D for ecrit@ietf.org; Thu, 17 May 2007 18:23:09 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HooLK-0001k7-5O; Thu, 17 May 2007 17:21:06 -0500 From: "Brian Rosen" To: "'Karihaloo, Ujjval'" , References: <8EAEBD84136584449B84AC177199EC4902F94A45@idc1exc0004.corp.global.level3.com> Subject: RE: [Ecrit] i2 NOmadic 911 using TDM interconnect Date: Thu, 17 May 2007 18:23:04 -0400 Message-ID: <040201c798d1$f1b27620$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceYzf4wMAVdzJYeTfCnjI0Nn8ghZAAAT3WQ In-reply-to: <8EAEBD84136584449B84AC177199EC4902F94A45@idc1exc0004.corp.global.level3.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.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: 9c7d7a899dc8f3389bf7ace6f0ad8e29 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="===============1716235643==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1716235643== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0403_01C798B0.6AA0D620" This is a multi-part message in MIME format. ------=_NextPart_000_0403_01C798B0.6AA0D620 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit This is DEFINITELY not the list to ask such a question. For i2 information, you need to go over to NENA and ask there. I'll answer it though :-) Let's start with some basics: i2 is for VoIP 9-1-1 calls. Calls start as VoIP. i2 uses a service (Level(3) is one of the vendors that offer this service) it's called an "Emergency Services Gateway" network. The ESGW takes a SIP call on the IP side and puts it into a Selective Router, usually via SS7. The SS7 connection from the ESGW almost always goes directly to an SR, or goes through a switch to an SR. I'm not aware of any ESGW network that hands the call off to another network. The actual TN of the caller does not make it to the PSAP via any PSTN signaling in the current i2 spec. All the PSAP gets is the ESQK, and it gets that as ANI. The actual TN of the caller is sent to the PSAP via its ALI dip. The gateway maps the P-Asserted-Identity, which should be the ESQK to the Calling Party Number and/or Charge Number in the IAM. The called party number is 9-1-1. The SR routes based on ANI to the right PSAP. ANI in this case is the ESQK. See: http://www.nena.org/media/files/03-503_20051020.pdf In there you can find section 4.1.3 that tells you how to populate the fields. Just for completeness however, there are some changes coming in i2.5, which the above document anticipates, which provides a mechanism to deliver the actual TN of the caller (the "Call Back Number") in the IAM. See section 4.1.4. It uses the GDP field for the ESQK and the CPN/CHGN for the Call Back Number. Brian _____ From: Karihaloo, Ujjval [mailto:Ujjval.Karihaloo@Level3.com] Sent: Thursday, May 17, 2007 5:55 PM To: ecrit@ietf.org Subject: [Ecrit] i2 NOmadic 911 using TDM interconnect Hi All, Is there any guidance on how to do an SS7 handoff to a Carrier for a Nomadic 911 Call flow? I understand i2 call flow requires an ESRN and ESQK to be carried as called and calling numbers, where do we actually populate the Actual ANI in the IAM message whilst handing the 911 Call off to a Carrier (who then hands it off to a PSAP)? Ujjval Karihaloo ------=_NextPart_000_0403_01C798B0.6AA0D620 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

This is DEFINITELY not the list to = ask such a question.  For i2 information, you need to go over to NENA = and ask there.

 

I’ll answer it though = J

 

Let’s start with some = basics:

i2 is for VoIP 9-1-1 calls.  = Calls start as VoIP.

i2 uses a service (Level(3) is one = of the vendors that offer this service) it’s called an “Emergency = Services Gateway” network.  The ESGW takes a SIP call on the IP side = and puts it into a Selective Router, usually via = SS7.

The SS7 connection from the ESGW = almost always goes directly to an SR, or goes through a switch to an SR.  = I’m not aware of any ESGW network that hands the call off to another = network.

The actual TN of the caller does = not make it to the PSAP via any PSTN signaling in the current i2 spec.  All = the PSAP gets is the ESQK, and it gets that as ANI.  The actual TN of = the caller is sent to the PSAP via its ALI dip.

The gateway maps the = P-Asserted-Identity, which should be the ESQK to the Calling Party Number and/or Charge = Number in the IAM.  The called party number is 9-1-1.  The SR routes = based on ANI to the right PSAP.  ANI in this case is the ESQK.  = See:

http://www.n= ena.org/media/files/03-503_20051020.pdf

 

In there you can find section 4.1.3 = that tells you how to populate the fields.

 

Just for completeness however, = there are some changes coming in i2.5, which the above document anticipates, which provides a mechanism to deliver the actual TN of the caller (the = “Call Back Number”) in the IAM.  See section 4.1.4.  It uses = the GDP field for the ESQK and the CPN/CHGN for the Call Back = Number.

 

Brian

 

From: = Karihaloo, Ujjval [mailto:Ujjval.Karihaloo@Level3.com]
Sent: Thursday, May 17, = 2007 5:55 PM
To: ecrit@ietf.org
Subject: [Ecrit] i2 = NOmadic 911 using TDM interconnect

 

Hi All,

 

     Is there any guidance on how = to do an SS7 handoff to a Carrier for a Nomadic 911 Call flow? I understand i2 = call flow requires an ESRN and ESQK to be carried as called and calling = numbers, where do we actually populate the Actual ANI in the IAM message whilst = handing the 911 Call off to a Carrier (who then hands it off to a = PSAP)?

 

 

Ujjval = Karihaloo

 

------=_NextPart_000_0403_01C798B0.6AA0D620-- --===============1716235643== 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 --===============1716235643==-- From ecrit-bounces@ietf.org Thu May 17 19:12:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hop8r-0006T6-Lv; Thu, 17 May 2007 19:12:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hop8q-0006Ln-0v for ecrit@ietf.org; Thu, 17 May 2007 19:12:16 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hop8p-0002yc-L5 for ecrit@ietf.org; Thu, 17 May 2007 19:12:16 -0400 X-SEF-Processed: 5_0_0_910__2007_05_17_18_19_23 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 17 May 2007 18:19:22 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 May 2007 18:12:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] i2 NOmadic 911 using TDM interconnect Date: Thu, 17 May 2007 18:12:10 -0500 Message-ID: In-Reply-To: <8EAEBD84136584449B84AC177199EC4902F94A45@idc1exc0004.corp.global.level3.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] i2 NOmadic 911 using TDM interconnect Thread-Index: AceYzf4wMAVdzJYeTfCnjI0Nn8ghZAACmf0g References: <8EAEBD84136584449B84AC177199EC4902F94A45@idc1exc0004.corp.global.level3.com> From: "Winterbottom, James" To: "Karihaloo, Ujjval" , X-OriginalArrivalTime: 17 May 2007 23:12:12.0965 (UTC) FILETIME=[CD64ED50:01C798D8] X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab 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="===============1608244716==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1608244716== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C798D8.CD366100" This is a multi-part message in MIME format. ------_=_NextPart_001_01C798D8.CD366100 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ujjal,=0D=0A=0D=0A=20=0D=0A=0D=0AI haven't looked at this for a while, b= ut as far as I recall, the ESRN=0D=0Ais oly used by the ESGW to select the = trunk-group and trunk to the=0D=0ASelective Router, and doesn't need to pop= ulated into the IAM at all. The=0D=0AESQK, is very similar to the ESRK use = din cellular, and is populated=0D=0Ainto the calling-party number, while th= e called-number is set to 911.=0D=0AThe selective-router normally takes the= calling-party number and=0D=0Apopulates this into the ANI or P-ANI and sen= ds this to the PSAP.=0D=0A=0D=0A=20=0D=0A=0D=0ACheers=0D=0A=0D=0AJames=0D=0A=0D= =0A=20=0D=0A=0D=0A________________________________=0D=0A=0D=0AFrom: Karihal= oo, Ujjval [mailto:Ujjval.Karihaloo@Level3.com]=20=0D=0ASent: Friday, 18 Ma= y 2007 7:55 AM=0D=0ATo: ecrit@ietf.org=0D=0ASubject: [Ecrit] i2 NOmadic 911= using TDM interconnect=0D=0A=0D=0A=20=0D=0A=0D=0AHi All,=0D=0A=0D=0A=20=0D= =0A=0D=0A Is there any guidance on how to do an SS7 handoff to a Carrie= r for=0D=0Aa Nomadic 911 Call flow=3F I understand i2 call flow requires an= ESRN and=0D=0AESQK to be carried as called and calling numbers, where do w= e actually=0D=0Apopulate the Actual ANI in the IAM message whilst handing t= he 911 Call=0D=0Aoff to a Carrier (who then hands it off to a PSAP)=3F=0D=0A=0D= =0A=20=0D=0A=0D=0A=20=0D=0A=0D=0AUjjval Karihaloo=0D=0A=0D=0A=20=0D=0A=0D=0A= ---------------------------------------------------------------------------= ---------------------=0D=0AThis message is for the designated recipient onl= y and may=0D=0Acontain privileged, proprietary, or otherwise private inform= ation. =20=0D=0AIf you have received it in error, please notify the sender=0D= =0Aimmediately and delete the original. Any unauthorized use of=0D=0Athis = email is prohibited.=0D=0A-------------------------------------------------= -----------------------------------------------=0D=0A[mf2]=0D=0A ------_=_NextPart_001_01C798D8.CD366100 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A= =0D=0A= =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A
=0D=0A=0D=0A

Hi= Ujjal,

=0D=0A=0D=0A

 

=0D=0A=0D=0A=

I haven’t looke= d at this for a=0D=0Awhile, but as far as I recall, the ESRN is oly used by= the ESGW to select the=0D=0Atrunk-group and trunk to the Selective Router,= and doesn’t need to=0D=0Apopulated into the IAM at all. The ESQK, is= very similar to the ESRK use din=0D=0Acellular, and is populated into the = calling-party number, while the called-number=0D=0Ais set to 911. The selec= tive-router normally takes the calling-party number and=0D=0Apopulates this= into the ANI or P-ANI and sends this to the PSAP.=

=0D=0A=0D=0A

 

=0D=0A=0D=0A

Cheers

=0D=0A=0D=0A

James

=0D=0A=0D=0A

<= o:p> 

=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D= =0A
=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A

From:=0D=0AKarihaloo, Ujjval [mailto:Ujjval.Karihaloo@Level3.com]
=0D= =0ASent: Friday, 18 May 2007= 7:55 AM
=0D=0ATo: ecrit@= ietf.org
=0D=0ASubject: [= Ecrit] i2 NOmadic 911=0D=0Ausing TDM interconnect

=0D=0A=0D=0A
=0D=0A=0D=0A

 

=0D=0A=0D=0A

Hi All,

=0D=0A=0D=0A

<= span lang=3DEN-US style=3D'font-size:=0D=0A10.0pt;font-family:Arial'> =

=0D=0A=0D=0A

     Is there any g= uidance on how=0D=0Ato do an SS7 handoff to a Carrier for a Nomadic 911 Cal= l flow=3F I understand i2=0D=0Acall flow requires an ESRN and ESQK to be ca= rried as called and calling=0D=0Anumbers, where do we actually populate the= Actual ANI in the IAM message whilst=0D=0Ahanding the 911 Call off to a Ca= rrier (who then hands it off to a PSAP)=3F

=0D=0A=0D=0A

 

=0D=0A=0D= =0A

 

=0D=0A=0D=0A

Ujjval=0D=0AKarihaloo=

=0D=0A=0D=0A=

 

=0D= =0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A


----------------------------------------= --------------------------------------------------------
=0D=0AThis = ;message is for the designated recipient only=  and may
=0D=0Acontain privileged, proprietary, = ;or otherwise private information.  
=0D=0AIf&n= bsp;you have received it in error, please&nbs= p;notify the sender
=0D=0Aimmediately and delete&nbs= p;the original.  Any unauthorized use of
=0D= =0Athis email is prohibited.
=0D=0A----------------------= --------------------------------------------------------------------------<= br>=0D=0A[mf2]
=0D=0A=0D=0A=0D=0A ------_=_NextPart_001_01C798D8.CD366100-- --===============1608244716== 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 --===============1608244716==-- From ecrit-bounces@ietf.org Tue May 29 15:21:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht7Fy-0002X0-SP; Tue, 29 May 2007 15:21:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht7Fx-0002VN-BI for ecrit@ietf.org; Tue, 29 May 2007 15:21:21 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ht7Fv-0002Ha-PF for ecrit@ietf.org; Tue, 29 May 2007 15:21:21 -0400 Received: (qmail invoked by alias); 29 May 2007 19:21:17 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp038) with SMTP; 29 May 2007 21:21:17 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19OST4VsLRO8fFbW3OrbyxqfbtHLw5PY/QIepSto5 rQ8AxgzfUcU+CQ Message-ID: <465C7D2A.7000805@gmx.net> Date: Tue, 29 May 2007 21:21:14 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) 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: cf4fa59384e76e63313391b70cd0dd25 Subject: [Ecrit] Secretary X-BeenThere: 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, based on our discussion with Marc and our ADs we decided to add Roger as the working group secretary. The job involves: - Tracking Agenda Requests (collecting and uploading presentations) - Dealing with minutes, blue sheets, scribes - Tracking what needs to happen on drafts, making sure it happens, pinging people to meet deadlines Thank you Roger for volunteering. Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 29 15:23:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht7I8-0003OO-1m; Tue, 29 May 2007 15:23:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht7I7-0003OJ-Hx for ecrit@ietf.org; Tue, 29 May 2007 15:23:35 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht7I6-0002XI-71 for ecrit@ietf.org; Tue, 29 May 2007 15:23:35 -0400 X-SEF-Processed: 5_0_0_910__2007_05_29_14_30_53 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 29 May 2007 14:30:53 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 May 2007 14:23:30 -0500 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] Secretary Date: Tue, 29 May 2007 14:23:28 -0500 Message-ID: In-Reply-To: <465C7D2A.7000805@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Secretary Thread-Index: AceiJo6/VyUFgMr+S92ImaYQn4XpzQAAEL2Q References: <465C7D2A.7000805@gmx.net> From: "Winterbottom, James" To: "Hannes Tschofenig" , "ECRIT" X-OriginalArrivalTime: 29 May 2007 19:23:30.0057 (UTC) FILETIME=[D6DC5790:01C7A226] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Roger Marshall=3F=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Hann= es Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=0D=0A> Sent: Wednesday, 30= May 2007 5:21 AM=0D=0A> To: ECRIT=0D=0A> Subject: [Ecrit] Secretary=0D=0A>= =20=0D=0A> Hi all,=0D=0A>=20=0D=0A> based on our discussion with Marc and o= ur ADs we decided to add Roger=0D=0Aas=0D=0A> the working group secretary.=0D= =0A>=20=0D=0A> The job involves:=0D=0A> - Tracking Agenda Requests (collec= ting and uploading presentations)=0D=0A> - Dealing with minutes, blue sheet= s, scribes=0D=0A> - Tracking what needs to happen on drafts, making sure it= happens,=0D=0A> pinging people to meet deadlines=0D=0A>=20=0D=0A> Thank yo= u Roger for volunteering.=0D=0A>=20=0D=0A> Ciao=0D=0A> Hannes & Marc=0D=0A>= =20=0D=0A>=20=0D=0A> _______________________________________________=0D=0A>= Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https://www1.ietf.org/mail= man/listinfo/ecrit=0D=0A=0D=0A---------------------------------------------= ---------------------------------------------------=0D=0AThis message is fo= r the designated recipient only and may=0D=0Acontain privileged, proprietar= y, or otherwise private information. =20=0D=0AIf you have received it in er= ror, please notify the sender=0D=0Aimmediately and delete the original. An= y unauthorized use of=0D=0Athis email is prohibited.=0D=0A-----------------= ---------------------------------------------------------------------------= ----=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 29 15:24:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht7JM-000525-R7; Tue, 29 May 2007 15:24:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht7JL-0004zU-2l for ecrit@ietf.org; Tue, 29 May 2007 15:24:51 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht7JJ-0002rH-EL for ecrit@ietf.org; Tue, 29 May 2007 15:24:51 -0400 Received: from mail2.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id l4TJOkmw030711; Tue, 29 May 2007 21:24:46 +0200 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id l4TJOkfO028319; Tue, 29 May 2007 21:24:46 +0200 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 May 2007 21:24:45 +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] Secretary Date: Tue, 29 May 2007 21:24:42 +0200 Message-ID: <8F6CBC7005099442AECDB784C9E9D7E701BB3937@MCHP7R6A.ww002.siemens.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Secretary Thread-Index: AceiJo6/VyUFgMr+S92ImaYQn4XpzQAAEL2QAAAH42A= From: "Tschofenig, Hannes" To: "ext Winterbottom, James" , "Hannes Tschofenig" , "ECRIT" X-OriginalArrivalTime: 29 May 2007 19:24:45.0959 (UTC) FILETIME=[041A1170:01C7A227] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 > Roger Marshall? Yes.=20 >=20 > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Wednesday, 30 May 2007 5:21 AM > > To: ECRIT > > Subject: [Ecrit] Secretary > >=20 > > Hi all, > >=20 > > based on our discussion with Marc and our ADs we decided to=20 > add Roger > as > > the working group secretary. > >=20 > > The job involves: > > - Tracking Agenda Requests (collecting and uploading presentations) > > - Dealing with minutes, blue sheets, scribes > > - Tracking what needs to happen on drafts, making sure it happens, > > pinging people to meet deadlines > >=20 > > Thank you Roger for volunteering. > >=20 > > Ciao > > Hannes & Marc > >=20 > >=20 > > _______________________________________________ > > 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. =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] >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 29 18:49:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtAV5-0000N4-Ep; Tue, 29 May 2007 18:49:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtAV3-0000Mk-Ne for ecrit@ietf.org; Tue, 29 May 2007 18:49:09 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtAV2-0004hZ-7l for ecrit@ietf.org; Tue, 29 May 2007 18:49:09 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 29 May 2007 15:49:07 -0700 X-IronPort-AV: i="4.14,590,1170662400"; d="scan'208"; a="156041288:sNHT43909740" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4TMn7es001074; Tue, 29 May 2007 15:49:07 -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 l4TMmpaS025765; Tue, 29 May 2007 22:49:00 GMT 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); Tue, 29 May 2007 15:48:55 -0700 Received: from jmpolk-wxp.cisco.com ([171.71.119.227]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 May 2007 15:48:55 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 29 May 2007 17:48:54 -0500 To: "Tschofenig, Hannes" , "ext Winterbottom, James" , "Hannes Tschofenig" , "ECRIT" From: "James M. Polk" Subject: Re: AW: [Ecrit] Secretary In-Reply-To: <8F6CBC7005099442AECDB784C9E9D7E701BB3937@MCHP7R6A.ww002.si emens.net> References: <8F6CBC7005099442AECDB784C9E9D7E701BB3937@MCHP7R6A.ww002.siemens.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 29 May 2007 22:48:55.0298 (UTC) FILETIME=[8946DE20:01C7A243] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1847; t=1180478947; x=1181342947; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20AW=3A=20[Ecrit]=20Secretary |Sender:=20; bh=92R5UsstcnQjaTXUQ81dfGo8HWOO8U9N2y4sKv9fbXI=; b=dEx5mRmRkBDamwdkzACLwCXadl9/5Yu8gT3Tm6bkxWKews4uhaUBQkO/9wW2lAghvIQ0ohPc fNy5dNrD1j+mTC+Uwb5xIXhotZc6pedGzLWxJsQljiGA0K/PKRgJO5zfs6Tc6CFbdGsU+JAsEZ uzvzwueJqMecz7tFWa1LrhPlk=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 02:24 PM 5/29/2007, Tschofenig, Hannes wrote: > > Roger Marshall? >Yes. (pssst... Roger... what were you thinking?!) > > > > > -----Original Message----- > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > Sent: Wednesday, 30 May 2007 5:21 AM > > > To: ECRIT > > > Subject: [Ecrit] Secretary > > > > > > Hi all, > > > > > > based on our discussion with Marc and our ADs we decided to > > add Roger > > as > > > the working group secretary. > > > > > > The job involves: > > > - Tracking Agenda Requests (collecting and uploading presentations) > > > - Dealing with minutes, blue sheets, scribes > > > - Tracking what needs to happen on drafts, making sure it happens, > > > pinging people to meet deadlines > > > > > > Thank you Roger for volunteering. > > > > > > Ciao > > > Hannes & Marc > > > > > > > > > _______________________________________________ > > > 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit